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Preface 


This Application Guide describes how to configure and use the Web OS 9.0 software included 
in the Alteon WebSystems family of Web switches. For documentation on installing the 
switches physically, see the Hardware Installation Guide for your particular switch model. 


Who Should Use This Guide 


This Application Guide is intended for network installers and system administrators engaged in 
configuring and maintaining a network. The administrator should be familiar with Ethernet 
concepts, IP addressing. Spanning Tree Protocol, and SNMP configuration parameters. 


What You’ll Find in This Guide 


This guide will help you plan, implement, and administer Web OS software. Where possible, 

each section provides feature overviews, usage examples, and configuration instructions. 

Part 1: Basic Switching & Routing 

■ Chapter 1, “Basic IP Routing,” describes how to configure the Web switch for IP routing 
using IP subnets. Border Gateway Protocol (BGP), or DHCP Relay. 

■ Chapter 2, “VLANs,” describes how to configure Virtual Local Area Networks (VLANs) 
for creating separate network segments, including how to use VLAN tagging for devices 
that use multiple VLANs. 

■ Chapter 3, “Jumbo Frames,” describes using Alteon WebSystems extended Ethernet 
frames size to ease server processing overhead. 

■ Chapter 4, “Port Trunking,” describes how to group multiple physical ports together to 
aggregate the bandwidth between large-scale network devices. 

■ Chapter 5, “Secure Switch Management,” describes how to manage the switch using spe¬ 
cific IP addresses, RADIUS authentication. Secure Shell (SSH), and Secure Copy (SCP). 
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Part 2: Web Switching Fundamentals 

■ Chapter 6, “Server Load Balancing,” describes how to configure the Web switch to bal¬ 
ance network traffic among a pool of available servers for more efficient, robust, and scal¬ 
able network services. 

■ Chapter 7, “Filtering,” describes how to configure and optimize network traffic filters for 
security and Network Address Translation purposes. 

■ Chapter 8, “Application Redirection,” describes how to use filters for redirecting traffic to 
such network streamlining devices as Web caches. 

■ Chapter 9, “Virtual Matrix Architecture,” describes how to optimize system resources by 
distributing the workload to multiple processors. 

■ Chapter 10, “Health Checking,” describes how to configure the Web switch to recognize 
the availability of the various network resources used with the various load-balancing and 
application redirection features. 

■ Chapter 11, “High Availability,” describes how to use the Virtual Router Redundancy Pro¬ 
tocol (VRRP) to ensure that network resources remain available if one Web switch fails. 

Part 3: Advanced Web Switching 

■ Chapter 12, “Global Server Load Balancing,” describes configuring Server Load Balanc¬ 
ing across multiple geographic sites. 

■ Chapter 13, “Firewall Load Balancing,” describes how to combine features to provide a 
scalable solution for load balancing multiple firewalls. 

■ Chapter 14, “Virtual Private Network Load Balancing,” describes using your Web switch 
to load balance secure point-to-point links. 

■ Chapter 15, “Content Intelligent Switching,” describes how to perform load balancing and 
application redirection based on Layer 7 packet content information (such as URL, HTTP 
Header, browser type, and cookies). 

■ Chapter 16, “Persistence,” describes how to ensure that all connections from a specific cli¬ 
ent session reach the same server. Persistence can be based on cookies or SSL session ID. 

■ Chapter 17, “Bandwidth Management,” describes how to configure the Web switch for 
allocating specific portions of the available bandwidth for specific users or applications. 
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Typographic Conventions 


The following table describes the typographic styles used in this book. 

Table 1 

Typographic Conventions 


Typeface or 
Symbol 

Meaning 

Example 

AaBbCcl23 

This type is used for names of commands, 
files, and directories used within the text. 

View the readme . txt file. 


It also depicts on-screen computer output and 
prompts. 

Main# 

AaBbCcl23 

This bold type appears in command exam¬ 
ples. It shows text that must be typed in 
exactly as shown. 

Main# sys 

<AaBbCcl23> 

This italicized type appears in command 
examples as a parameter placeholder. Replace 
the indicated text with the appropriate real 
name or value when using the command. Do 
not type the brackets. 

To establish a Telnet session, enter: 
host# telnet <1P address> 


This also shows book titles, special terms, or 
words to be emphasized. 

Read your User’s Guide thoroughly. 

[ ] 

Command items shown inside brackets are 
optional and can be used or excluded as the 
situation demands. Do not type the brackets. 

host# Is [-a] 
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Contacting Alteon WebSystems 


Use the following information to access Alteon WebSystems’ support and sales. 

■ URL for Alteon WebSystems Online: 

http://www.alteonwebsystems.com 

This website includes product information, software updates, release notes, and white 
papers. The website also includes access to Alteon WebSystems Customer Support for 
accounts under warranty or covered by a maintenance contract. 

■ E-mail access: 

support@alteon.com 

E-mail access to Alteon WebSystems Customer Support is available for accounts under 
warranty or covered by a maintenance contract. 

■ Telephone access to Alteon WebSystems Customer Support: 

1-888-AlteonO (or 1-888-258-3660) 

1-408-360-5695 

Telephone access to Alteon WebSystems Customer Support is available to accounts that 
are under warranty or covered by a maintenance contract. Normal business hours are 
8 a.m. to 6 p.m. Pacific Standard Time. 

■ Telephone access to Alteon WebSystems Sales: 

l-888-Alteon2 (or 1-888-258-3662), and press 2 for Sales 
1-408-360-5600, and press 2 for Sales 

Telephone access is available for information regarding product sales and upgrades. 
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Part 1: Basic Switching & 
Routing 


This section discusses basic Layer 1 through Layer 3 switching and routing functions. In addi¬ 
tion to switching traffic at near line rates, the Web switch can perform multi-protocol routing. 

■ Basic IP Routing 

■ VLANs 

■ Jumbo Frames 

■ Port Trunking 

■ Border Gateway Protocol 

■ Secure Switch Management 


Alteon M^^Systems 21 

050159A, May 2001 



Web OS 9.0 Application Guide 


22 ■ Basic Switching & Routing 


Alteon ((^Systems 

050159A, May 2001 


Chapter 1 

Basic IP Routing 


This chapter provides configuration background and examples for using the Alteon Web switch 
to perform IP routing functions. 

■ “IP Routing Benefits” on page 23 

■ “Routing Between IP Subnets” on page 24 

■ “Example of Subnet Routing” on page 26 

■ “Defining IP Address Ranges for the Local Route Cache” on page 31 

■ “Border Gateway Protocol (BGP)” on page 32 

■ “DHCP Relay” on page 37 

IP Routing Benefits 


The Alteon Web switch uses a combination of configurable IP switch interfaces and IP routing 

options. The switch IP routing capabilities provide the following benefits: 

■ Connects the server IP subnets to the rest of the backbone network 

■ Performs server load balancing (using both Layer 3 and Layer 4 switching in combina¬ 
tion) to server subnets that are separate from backbone subnets 

■ Provides another means to invisibly introduce Jumbo frame technology into the server- 
switched network by automatically fragmenting UDP Jumbo frames when routing to non- 
Jumbo frame VLANs or subnets 

■ Provides the ability to route IP traffic between multiple Virtual Local Area Networks 
(VLANs) configured on the switch 
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Routing Between IP Subnets 


The physical layout of most corporate networks has evolved over time. Classic hub/router 
topologies have given way to faster switched topologies, particularly now that switches are 
increasingly intelligent. Alteon Web switches are intelligent and fast enough to perform rout¬ 
ing functions on a par with wire speed Layer 2 switching. 

The combination of faster routing and switching in a single device provides another service: it 
allows you to build versatile topologies that account for legacy configurations. 

For example, consider the following topology migration: 



Figure 1-1 The Router Legacy Network 

In this example, a corporate campus has migrated from a router-centric topology to a faster, 
more powerful, switch-based topology. As is often the case, the legacy of network growth and 
redesign has left the system with a mix of illogically distributed subnets. 
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This is a situation that switching alone cannot cure. Instead, the router is flooded with cross¬ 
subnet communication. This compromises efficiency in two ways: 

■ Routers can be slower than switches. The cross-subnet side trip from the switch to the 
router and back again adds two hops for the data, slowing throughput considerably. 

■ Traffic to the router increases, worsening any congestion. 

Even if every end-station could be moved to better logical subnets (a daunting task), competi¬ 
tion for access to common server pools on different subnets still burdens the routers. 

This problem is solved by using Alteon Web switches with built-in IP routing capabilities. 
Cross-subnet LAN traffic can now be routed within the Web switches with wire speed Layer 2 
switching performance. This not only eases the load on the router but saves the network 
administrators from reconfiguring each and every end-station with new IP addresses. 

Take a closer look at the Alteon Web switch in the following configuration example: 


First Floor Second Floor Third Floor 

10/100 Client Subnet 10/100 Client Subnet 10/100 Client Subnet 

100 . 20 . 10 . 1-254 131 . 15 . 15 . 1-254 208 . 31 . 177 . 1-254 



Secondary Default Server Subnet: 

Router: 205 . 21 . 17.2 Alteon Web Switch 206 . 30 . 15 . 1-254 


Figure 1-2 Switch-Based Routing Topology 


The Alteon Web switch connects the Gigabit Ethernet and Fast Ethernet trunks from various 
switched subnets throughout one building. Common servers are placed on another subnet 
attached to the switch. A primary and backup router are attached to the switch on yet another 
subnet. 

Without Layer 3 IP routing on the switch, cross-subnet communication is relayed to the default 
gateway (in this case, the router) for the next level of routing intelligence. The router fills in the 
necessary address information and sends the data back to the switch, which then relays the 
packet to the proper destination subnet using Layer 2 switching. 
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With Layer 3 IP routing in place on the Alteon Web switch, routing between different IP sub¬ 
nets can be accomplished entirely within the switch. This leaves the routers free to handle 
inbound and outbound traffic for this group of subnets. 

To make implementation even easier, UDP Jumbo frame traffic is automatically fragmented to 
regular Ethernet frame sizes when routing to non-Jumbo frame VLANS or subnets. This auto¬ 
matic frame conversion allows servers to communicate using Jumbo frames, all transparently 
to the user. 


Example of Subnet Routing 


Prior to configuration, you must be connected to the switch Command Line Interface (CLI) as 
the administrator. 


NOTE — For details about accessing and using any of the menu commands described in this 
example, see the Web OS Command Reference. 

1. Assign an IP address (or document the existing one) for each real server, router, and cli¬ 
ent workstation. 

In our example topology in Figure 1-2 on page 25, the following IP addresses are used: 


Table 1-1 Subnet Routing Example: IP Address Assignments 


Subnet 

Devices 

IP Addresses 

1 

Primary and Secondary Default Routers 

205.21.17.1 and 205.21.17.2 

2 

First Floor Client Workstations 

100.20.10.1-254 

3 

Second Floor Client Workstations 

131.15.15.1-254 

4 

Third Floor Client Workstations 

208.31.177.1-254 

5 

Common Servers 

206.30.15.1-254 
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2. On the switch, assign an IP interface for each subnet attached to the switch. 

Since there are five IP subnets connected to the switch, five IP interfaces are needed: 


Table 1-2 Subnet Routing Example: IP Interface Assignments 


Interface 

Devices 

IP Interface Address 

IF 1 

Primary and Secondary Default Routers 

205.21.17.3 

IF 2 

First Floor Client Workstations 

100.20.10.16 

IF 3 

Second Floor Client Workstations 

131.15.15.1 

IF 4 

Third Floor Client Workstations 

208.31.177.2 

IF 5 

Common Servers 

206.30.15.200 


IP interfaces are configured using the following commands at the CLI: 


>> 

# 

/cfg/ip/if 

1 


(Select IP interface 1) 

>> 

IP 

Interface 

1# 

addr 205.21.17.3 

(Assign IP address for the interface) 

>> 

IP 

Interface 

1# 

ena 

(Enable IP interface 1) 

>> 

IP 

Interface 

1# 

../if 2 

(Select IP interface 2) 

>> 

IP 

Interface 

2# 

addr 100.20.10.16 

(Assign IP address for the interface) 

>> 

IP 

Interface 

2# 

ena 

(Enable IP interface 2) 

>> 

IP 

Interface 

2# 

../if 3 

(Select IP interface 3) 

>> 

IP 

Interface 

3# 

addr 131.15.15.1 

(Assign IP address for the interface) 

>> 

IP 

Interface 

3# 

ena 

(Enable IP interface 3) 

>> 

IP 

Interface 

3# 

../if 4 

(Select IP interface 4) 

>> 

IP 

Interface 

4# 

addr 208.31.177.2 

(Assign IP address for the interface) 

>> 

IP 

Interface 

4# 

ena 

(Enable IP interface 4) 

>> 

IP 

Interface 

4# 

../if 5 

(Select IP interface 5) 

>> 

IP 

Interface 

5# 

addr 206.30.15.200 

(Assign IP address for the interface) 

>> 

IP 

Interface 

5# 

ena 

(Enable IP interface 5) 


3. Set each server and workstation’s default gateway to the appropriate switch IP interface 
(the one in the same subnet as the server or workstation). 
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4. On the switch, configure the default gateways to the routers addresses. 

Configuring the default gateways allows the switch to send outbound traffic to the routers: 


>> 

IP Inte 

rface 5# 

■ -/gw l 


f Select primary default gateway) 

>> 

Default 

gateway 

i# 

addr 

205.21.17.1 

(Assign IP address for primary router) 

>> 

Default 

gateway 

i# 

ena 


(Enable primary default gateway) 

>> 

Default 

gateway 

i# 

■ ■/gw 2 

(Select secondary default gateway) 

>> 

Default 

gateway 

2# 

addr 

205.21.17.2 

(Assign address for secondary router) 

>> 

Default 

gateway 

2# 

ena 


(Enable secondary default gateway) 


5. On the switch, enable, apply, and verify the configuration. 


» 

Default gateway 2# ../fwrd 

(Select the IP Forwarding Menu) 

» 

IP 

Forwarding# 

on 

(Turn IP forwarding on) 

» 

IP 

Forwarding# 

apply 

(Make your changes active) 

» 

IP 

Forwarding# 

/cfg/ip/cur 

(View current IP settings) 


Examine the resulting information. If any settings are incorrect, make the appropriate changes. 

6. On the switch, save your new configuration changes. 


>> IP# save 


(Save for restore after reboot) 


Using VLANs to Segregate Broadcast Domains 

In the previous example, devices that share a common IP network are all in the same broadcast 
domain. If limiting broadcasts is desired in your network, you could use VLANs to create dis¬ 
tinct broadcast domains. For example, as shown in the following procedure, you could create 
one VLAN for the client trunks, one for the routers, and one for the servers. 

In this exercise, you are adding to the previous configuration. 


28 ■ Chapter 1: Basic IP Routing 


Alteon ((^Systems 

050159A, May 2001 





Web OS 9.0 Application Guide 


1. Determine which switch ports and IP interfaces belong to which VLANs. 

The following table adds port and VLAN information: 

Table 1-3 Subnet Routing Example: Optional VLAN Ports 


VLAN 

Devices 

IP Interface 

Switch Port 

1 

First Floor Client Workstations 

3 

1 


Second Floor Client Workstations 

4 

2 


Third Floor Client Workstations 

5 

3 

2 

Primary Default Router 

1 

4 


Secondary Default Router 

2 

5 

3 

Common Servers 1 

6 

6 


Common Servers 2 

7 

7 


2. On the switch, add the switch ports to their respective VLANs. 

The VLANs shown in Table 1-3 are configured as follows: 


>> 

# /cfg/vlan 1 


>> 

VLAN 

1# 

add port 

1 

>> 

VLAN 

1# 

add port 

2 

>> 

VLAN 

1# 

add port 

3 

>> 

VLAN 

1# 

ena 


>> 

VLAN 

1# 

../VLAN 2 


>> 

VLAN 

2# 

add port 

4 

>> 

VLAN 

2# 

add port 

5 

>> 

VLAN 

2# 

ena 


>> 

VLAN 

2# 

../VLAN 3 


>> 

VLAN 

3# 

add port 

6 

>> 

VLAN 

3# 

add port 

7 

>> 

VLAN 

3# 

ena 



(Select VLAN 1) 

(Add port for 1st floor to VLAN 1) 
(Add port for 2nd floor to VLAN 1) 
(Add port for 3rd floor to VLAN 1) 
(Enable VLAN 1) 

(,Select VLAN 2) 

(Add port for default router 1) 
(Add port for default router 2) 
(Enable VLAN 2) 

(Add port for default router 3) 
(Select VLAN 3) 

(Select port for common ser\>er 1) 
(Enable VLAN 3) 


When you add a port to a VLAN, you may get the following prompt: 


Port 4 is untagged and VLAN 2 is not a configured PVID for port 4. 
Would you like to change all PVIDS for port 4 to VLAN 2 [y n]? 


Enter y to set the default Port VLAN ID (PVID) for the port. 
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3. On the switch, add each IP interface to the appropriate VLAN. 

Now that the ports are separated into three VLANs, the IP interface for each subnet must be 
placed in the appropriate VLAN. From Table 1-3 on page 29, the settings are made as follows: 


>> 

VLAN 3# /cfg/ip/if 1 

(Select IP interface 1 for def. routers) 

>> 

IP 

Interface 

1# 

vlan 2 

(Set to VLAN 2) 

>> 

IP 

Interface 

1# 

. ./if 2 

(Select IP interface 2 for first floor) 

>> 

IP 

Interface 

2# 

vlan 1 

(Set to VLAN 1) 

>> 

IP 

Interface 

2# 

../if 3 

(Select IP interface 3 for second floor) 

>> 

IP 

Interface 

3# 

vlan 1 

(Set to VLAN 1) 

>> 

IP 

Interface 

3# 

. . /if 4 

(Select IP interface 4 for third floor) 

>> 

IP 

Interface 

4# 

vlan 1 

(Set to VLAN 1) 

>> 

IP 

Interface 

4# 

../if 5 

(Select IP interface 5 for servers) 

>> 

IP 

Interface 

5# 

vlan 3 

(Set to VLAN 3) 


4. Apply and verify the configuration. 


» IP Interface 

5# apply 

(Make your changes active) 

>> IP Interface 

5# /info/vlan 

(View current VLAN information) 

>> Information# 

port 

(View current port information) 


Examine the resulting information. If any settings are incorrect, make the appropriate changes. 

5. On the switch, save your new configuration changes. 


>> Information# save 


(Save for restore after reboot) 
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Defining IP Address Ranges for the Local 
Route Cache 


A local route cache lets you use switch resources more efficiently. The local network address 
and local network mask parameters (accessed via the /cf g/ip / frwd/local/add com¬ 
mand) define a range of addresses that will be cached on the switch. The local network address 
is used to define the base IP address in the range that will be cached. The local network mask is 
applied to produce the range. To determine if a route should be added to the memory cache, the 
destination address is masked (bit-wise AND) with the local network mask and checked 
against the local network address. 

By default, the local network address and local network mask are both set to 0.0.0.0. This pro¬ 
duces a range that includes all Internet addresses for route caching: 0.0.0.0 through 
255.255.255.255. 

To limit the route cache to your local hosts, you could configure the parameters as shown in the 
following example: 


Table 1-4 Local Routing Cache Address Ranges 


Local Host Address Range 

Local Network Address 

Local Network Mask 

0.0.0.0 - 127.255.255.255 

o.o.o.o 

128.0.0.0 

128.0.0.0- 128.255.255.255 

128.0.0.0 

128.0.0.0 or 255.0.0.0 

205.32.0.0-205.32.255.255 

205.32.0.0 

255.255.0.0 


NOTE — All addresses that fall outside the defined range are forwarded to the default gateway. 
The default gateways must be configured within range. 
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Border Gateway Protocol (BGP) 


Border Gateway Protocol (BGP) is an Internet protocol that enables routers on a network to 
share and advertise routing information with each other about the segments of the IP address 
space they can access within their network and with routers on external networks. BGP allows 
you to decide what is the “best” route for a packet to take from your network to a destination 
on another network rather than simply setting a default route from your border router(s) to your 
upstream provider(s). BGP is defined in RFC 1771. 

Alteon Web switches can advertise their IP interfaces and virtual IP addresses using BGP and 
take BGP feeds from as many as four BGP router peers. This allows more resilience and flexi¬ 
bility in balancing traffic from the Internet. 

Internal Routing Versus External Routing 

To ensure effective processing of network traffic, every router on your network needs to know 
how to send a packet (directly or indirectly) to any other location/destination in your network. 
This is referred to as internal routing and can be done with static routes or using active, inter¬ 
nal routing protocols, such as RIP, RIPv2, and OSPF. 

It is also useful to tell routers outside your network (upstream providers or peers ) about the 
routes you can access in your network. External networks (those outside your own) that are 
under the same administrative control are referred to as autonomous systems (AS). Sharing of 
routing information between autonomous systems is known as external routing. 

External BGP (eBGP) is used to exchange routes between different autonomous systems 
whereas internal BGP (iBGP) is used to exchange routes within the same autonomous system. 
An iBGP is a type of internal routing protocol you can use to do active routing inside your net¬ 
work. It also carries AS path information, which is important when you are an ISP or doing 
BGP transit. 
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NOTE — The iBGP peers have to be part of a fully meshed network, as shown in Figure 1-3. 



Figure 1-3 iBGP and eBGP 

Typically, an AS has one or more multiple border routers —peer routers that exchange routes 
with other ASs—and an internal routing scheme that enables routers in that AS to reach every 
other router and destination within that AS. When you advertise routes to border routers on 
other autonomous systems, you are effectively committing to carry data to the IP space repre¬ 
sented in the route being advertised. For example, if you advertise 192.204.4.0/24, you are 
declaring that if another router sends you data destined for any address in 192.204.4.0/24, you 
know how to carry that data to its destination. 

Forming BGP Peer Routers 

Two BGP routers become peers or neighbors once you establish a TCP connection between 
them. For each new route, if a peer is interested in that route (for example, if a peer would like 
to receive your static routes and the new route is static), an update message is sent to that peer 
containing the new route. For each route removed from the route table, if the route has already 
been sent to a peer, an update message containing the route to withdraw is sent to that peer. 

For each Internet host, you must be able to send a packet to that host, and that host has to have a 
path back to you. This means that whoever provides Internet connectivity to that host must have 
a path to you. Ultimately, this means that they must “hear a route” which covers the section of the 
IP space you are using; otherwise, you will not have connectivity to the host in question. 
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BGP Failover Configuration 

Use the following example to create redundant default gateways for an Alteon Web switch at a 
Web Host/ISP site, eliminating the possibility, should one gateway go down, that requests will 
be forwarded to an upstream router unknown to the switch. 

As shown in Figure 1-4, the switch is connected to ISP 1 and ISP 2. The customer negotiates 
with both ISPs to allow the Web switch to use their peer routers as default gateways. The ISP 
peer routers will then need to announce themselves as default gateways to the Web switch. 

ISP 2 ISP 1 


AS 200 AS 100 



Figure 1-4 BGP Failover Configuration Example 


On the Web switch, one peer router (the secondary one) is configured with a longer AS path 
than the other, so that the peer with the shorter AS path will be seen by the switch as the pri¬ 
mary default gateway. ISP 2, the secondary peer, is configured with a metric of “3,” thereby 
appearing to the switch to be three router hops away. 

1. Configure the switch as you normally would for Server Load Balancing (SLB). 

■ Assign an IP address to each of the real servers in the server pool. 

■ Define each real server. 

■ Define a real server group. 

■ Define a virtual server. 

■ Define the port configuration. 

For more information about SLB configuration, refer to Chapter 6. 
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2. Define the VLANs. 

For simplicity, both default gateways are configured in the same VLAN in this example. The 
gateways could be in the same VLAN or different VLANs. 


» # /cfg/vlan 1 

(Select VLAN 1) 

» vlan 1# add <port number> 

(Add a port to the VLAN membership) 

» vlan 1# ena 

(Enable VLAN 1) 


3. Define the IP interfaces. 

The switch will need an IP interface for each default gateway to which it will be connected. 
Each interface will need to be placed in the appropriate VLAN. These interfaces will be used 
as the primary and secondary default gateways for the switch. 


» 

/cfg/ip/rearp 10 

(Set re-ARP period for interface to 10) 

» 

IP# 

metre strict 

(Set metric for default gateway) 

» 

IP# 

if 1 



(Select default gateway inteiface 1) 

» 

IP 

Interface 

1# 

ena 

(Enable switch interface 1) 

» 

IP 

Interface 

1# 

addr 200.200.200.1 

(Configure IP address of inteiface 1) 

» 

IP 

Interface 

1# 

mask 255.255.255.0 

(Configure IP subnet address mask) 

» 

IP 

Interface 

1# 

broad 200.200.200.255 

(Configure IP broadcast address) 

» 

IP 

Interface 

1# 

vlan 1 

(Configure VLAN # for this interface) 

» 

IP 

Interface 

1# 

../ip/if 2 

(Select default gateway interface 2) 

» 

IP 

Interface 

2# 

ena 

(Enable switch interface 2) 

» 

IP 

Interface 

2# 

addr 210.210.210.1 

(Configure IP address of interface 2) 

» 

IP 

Interface 

2# 

mask 255.255.255.0 

(Configure IP subnet address mask) 

» 

IP 

Interface 

2# 

broad 210.210.210.255 

(Configure IP broadcast address) 

» 

IP 

Interface 

2# 

vlan 1 

(Configure VLAN # for this interface) 


4. Enable IP forwarding. 

IP forwarding is used for VLAN-to-VLAN (non-BGP) routing. You need to enable IP forward¬ 
ing if the default gateways are on different subnets or if the switch is connected to different 
subnets and those subnets need to communicate through the switch (which they almost always 
do). 


>> /cfg/ip/ frwd on 


(Enable IP forwarding) 


NOTE — To help eliminate the possibility for a Denial of Service (DoS) attack, the forwarding 
of directed broadcasts is disabled by default. 
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5. Configure BGP peer router 1 and 2. 

Peer 1 is the primary gateway router. Peer 2 is configured with a metric of “3.” The metric 
option is key to ensuring gateway traffic is directed to Peer 1, as it will make Peer 2 appear to 
be three router hops away from the switch. Thus, the switch should never use it unless Peer 1 
goes down. 


>> 

# /cfg/ip/bgp/peer 1 

f Select BGP peer router 1) 

>> 

BGP 

Peer 

1# 

ena 

(Enable this peer configuration) 

>> 

BGP 

Peer 

1# 

addr 200.200.200.2 

(Set IP address for peer router 1) 

>> 

BGP 

Peer 

1# 

if 200.200.200.1 

(Set IP interface for peer router 1) 

>> 

BGP 

Peer 

1# 

las 300 

(Set local AS number) 

>> 

BGP 

Peer 

1# 

ras 100 

(Set remote AS number) 

>> 

BGP 

Peer 

1# 

../peer 2 

(Select BGP peer router 2) 

>> 

BGP 

Peer 

2# 

ena 

(Enable this peer configuration) 

>> 

BGP 

Peer 

2# 

addr 200.200.200.2 

(Set IP address for peer router 2) 

>> 

BGP 

Peer 

2# 

if 210.210.210.1 

(Set IP interface for peer router 2) 

>> 

BGP 

Peer 

2# 

las 300 

(Set local AS number) 

>> 

BGP 

Peer 

2# 

ras 200 

(Set remote AS number) 

>> 

BGP 

Peer 

2# 

metric 3 

(Set AS path length to 3 router hops) 


The metric command in the peer menu tells the Alteon Web switch to create an AS path of “3” 
when advertising via BGP. 

6. On the switch, apply and save your configuration changes. 


» BGP Peer 2# apply 

(Make your changes active) 

>> save 

(Save for restore after reboot) 
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DHCP Relay 


Dynamic Host Configuration Protocol (DHCP) is a transport protocol that provides a frame¬ 
work for automatically assigning IP addresses and configuration information to other IP hosts 
or clients in a large TCP/IP network. Without DHCP, the IP address must be entered manually 
for each network device. DHCP allows a network administrator to distribute IP addresses from 
a central point and automatically send a new IP address when a device is connected to a differ¬ 
ent place in the network. 

DHCP is an extension of another network IP management protocol. Bootstrap Protocol 
(BootP), with an additional capability of being able to dynamically allocate reusable network 
addresses and configuration parameters for client operation. 

Built on the client/server model, DHCP allows hosts or clients on an IP network to obtain their 
configurations from a DHCP server, thereby reducing network administration. The most sig¬ 
nificant configuration the client receives from the server is its required IP address; (other 
optional parameters include the “generic” file name to be booted, the address of the default 
gateway, and so forth). 

Alteon WebSystems DHCP relay agent eliminates the need to have DHCP/BOOTP servers on 
every subnet. It allows the administrator to reduce the number of DHCP servers deployed on 
the network and to centralize them. Without the DHCP relay agent, there must be at least one 
DHCP server deployed at each subnet that has hosts needing to perform the DHCP request. 

DHCP Overview 

DHCP is described in RFC 2131, and the DHCP relay agent supported on Alteon Web 
switches is described in RFC 1542. DHCP uses UDP as its transport protocol. The client sends 
messages to the server on port 67 and the server sends messages to the client on port 68. 

DHCP defines the methods through which clients can be assigned an IP address for a finite 
lease period and allowing reassignment of the IP address to another client later. Additionally, 
DHCP provides the mechanism for a client to gather other IP configuration parameters it needs 
to operate in the TCP/IP network. 

In the DHCP environment, the Alteon Web switch acts as a relay agent. The DHCP relay fea¬ 
ture (/cfg/ip/bootp) enables the switch to forward a client request for an IP address to 
two BOOTP servers with IP addresses that have been configured on the switch. 

When a switch receives a UDP broadcast on port 67 from a DHCP client requesting an IP 
address, the switch acts as a proxy for the client, replacing the client source IP (SIP) and desti¬ 
nation IP (DIP) addresses. The request is then forwarded as a UDP Unicast MAC layer mes¬ 
sage to two BOOTP servers whose IP addresses are configured on the switch. The servers 
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respond as a a UDP Unicast message back to the switch, with the default gateway and IP 
address for the client. The destination IP (DIP) address in the server response represents the 
interface address on the switch that received the client request. This interface address tells the 
switch on which VLAN to send the server response to the client. 

DHCP Relay Agent Configuration 

To enable the Alteon Web switch to be the BOOTP forwarder, you need to configure the 
DHCP/BOOTP server IP addresses on the switch. Generally, you should configure the com¬ 
mand on the switch IP interface closest to the client so that the DHCP server knows from 
which IP subnet the newly allocated IP address should come. 

The following figure shows a basic DHCP network example: 


Boston Atlanta 



DHCP Alteon Web Switch/ DHCP 

Client DHCP Relay Agent Server 

Figure 1-5 DHCP Relay Agent Configuration 

In Alteon Web switch implementation, there is no need for primary or secondary servers. The 
client request is forwarded to the BOOTP servers configured on the switch. The use of two 
servers provides failover redundancy. However, no health checking is supported. 

Use the following commands to configure the switch as a DHCP relay agent: 


>> # /cfg/ip/bootp 


>> 

Bootstrap 

Protocol 

Relay# 

addr 

>> 

Bootstrap 

Protocol 

Relay# 

addr2 

>> 

Bootstrap 

Protocol 

Relay# 

on 

>> 

Bootstrap 

Protocol 

Relay# 

off 

>> 

Bootstrap 

Protocol 

Relay# 

cur 


(Set IP address of BOOTP server) 

(Set IP address of 2nd BOOTP server) 
(Globally turn BOOTP relay on) 

(Globally turn BOOTP relay off) 
(Display current configuration) 


Additionally, DHCP Relay functionality can be assigned on a per interface basis. Use the fol¬ 
lowing command to enable the Relay functionality: 


>> # /cfg/ip/if <interface number >/relay ena 
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Chapter 2 

VLANs 


This chapter describes network design and topology considerations for using Virtual Local Area 
Networks (VLANs). VLANs are commonly used to split up groups of network users into man¬ 
ageable broadcast domains, to create logical segmentation of workgroups, and to enforce security 
policies among logical segments. The following topics are discussed in this chapter: 

■ “VLAN ID Numbers” on page 40 

■ “VLAN Tagging” on page 40 

■ “VLANs and Spanning Tree Protocol” on page 41 

■ “VLANs and the IP Interfaces” on page 41 

This section briefly describes how management functions can only be accomplished from 
stations on VLANs that include an IP interface to the switch. 

■ “VLAN Topologies and Design Issues” on page 42 

This section discusses how you can logically connect users and segments to a host that 
supports many logical segments or subnets by using the flexibility of the multiple VLAN 
system. 


NOTE — Basic VLANs can be configured during initial switch configuration (see “Using the 
Setup Utility” in the Web OS Command Reference). More comprehensive VLAN configuration 
can be done from the Command Line Interface (see “VLAN Configuration” as well as “Port 
Configuration” in the Web OS Command Reference). 
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VLAN ID Numbers 


Web OS supports up to 246 VLANs per switch. Even though the maximum number of VLANs 
supported at any given time is 246, each can be identified with any number between 1^-094. 

VLANs are defined on a per-port basis. Each port on the switch can belong to one or more 
VLANs, and each VLAN can have any number of switch ports in its membership. Any port 
that belongs to multiple VLANs, however, must have VLAN tagging enabled (see “VLAN 
Tagging” on page 40). 

Each port in the switch has a configurable default VLAN number, known as its PVID. The fac¬ 
tory default value of all PVIDs is 1. This places all ports on the same VLAN initially, although 
each port’s PVID is configurable to any VLAN number between land 4094. 

Any nontagged frames (those with no VLAN specified) are classified with the sending port’s 
PVID. 

VLAN Tagging 


Web OS software supports 802.IQ VLAN tagging, providing standards-based VLAN support 
for Ethernet systems. 

Tagging places the VLAN identifier in the frame header, allowing multiple VLANs per port. 
When you configure multiple VLANs on a port, you must also enable tagging on that port. 

Since tagging fundamentally changes the format of frames transmitted on a tagged port, you 
must carefully plan network designs to prevent tagged frames from being transmitted to 
devices that do not support 802. IQ VLAN tags. 
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VLANs and Spanning Tree Protocol 


When Spanning Tree Protocol (STP) is enabled on the switch, it detects and eliminates logical 
loops in a bridged or switched network. When multiple paths exist, Spanning Tree configures 
the network so that a switch uses only the most efficient path. If that path fails. Spanning Tree 
automatically sets up another active path on the network to sustain network operations. 

If you configure the switch with STP, there will be a single instance of Spanning Tree per 
switch, regardless of the number of configured VLANs in an enabled state. 


VLANs and the IP Interfaces 


Careful consideration must be made when creating VLANs within the switch, such that com¬ 
munication with the switch Management Processor (MP) remains possible where it is required. 

Access to the switch for remote configuration, trap messages, and other management functions 
can only be accomplished from stations on VLANs that include an IP interface to the switch 
(see “IP Interface Menu” section in the Web OS Command Reference ). Likewise, access to 
management functions can be cut off to any VLAN by excluding IP interfaces from its mem¬ 
bership. 

For example, if all IP interfaces are left on VLAN 1 (the default), and all ports are configured 
for VLANs other than VLAN 1, then switch management features are effectively cut off. If an 
IP interface is added to one of the other VLANs, the stations in that VLAN all have access to 
switch management features. 
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VLAN Topologies and Design Issues 


By default, the Web OS 9.0 software has a single VLAN configured on every port. This config¬ 
uration groups all ports into the same broadcast domain. The VLAN has an 802. IQ VLAN 
PVID of 1. VLAN tagging is turned off, because by default only a single VLAN is configured 
per port. 

Since VLANs are most commonly used to create individual broadcast domains and/or separate 
IP subnets, it is useful for host systems to be able to have presence on more than one VLAN 
simultaneously. Alteon Web switches and ACEnic adapters have the unique capability of being 
able to support multiple VLANS on a per port or per interface basis, allowing very flexible 
configurations. 

You can configure multiple VLANs on a single ACEnic adapter, with each VLAN being con¬ 
figured through a logical interface and logical IP address on the host system. Each VLAN con¬ 
figured on the adapter must also be configured on the switch port to which it is connected. If 
multiple VLANs are configured on the port, tagging must be turned on. 

Using this flexible multiple VLAN system, you can logically connect users and segments to a 
host with a single ACEnic adapter that supports many logical segments or subnets. 


Example 1: Multiple VLANS with Tagging Adapters 
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Figure 2-1 Example 1: Multiple VLANs with Tagging ACEnic Adapters 
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The features of this VLAN are described below: 


Component 

Description 

Web Switch 

This switch is configured for three VLANs that represent three differ¬ 
ent IP subnets. Two servers and five clients are attached to the switch. 

Server 1 

This server is part of VLAN 3 and only has presence in one IP subnet. 
The port that the VLAN is attached to is configured only for VLAN 3, 
so VLAN tagging is off. 

Server 2 

This high-use server needs to be accessed from all VLANs and IP sub¬ 
nets. The server has an Alteon ACEnic adapter installed with VLAN 
tagging turned on. The adapter is attached to one of the Web switch’s 
Gigabit Ethernet ports, that is configured for VLANs 1, 2, and 3. Tag¬ 
ging is turned on. Because of the VLAN tagging capabilities of both the 
adapter and the switch, the server is able to communicate on all three IP 
subnets in this network. Broadcast separation between all three VLANs 
and subnets, however, is maintained. 

PCs 1 and 2 

These PCs are attached to a shared media hub that is then connected to 
the switch. They belong to VLAN 2 and are logically in the same IP 
subnet as Server 2 and PC 5. Tagging is not enabled on their switch 
port. 

PC 3 

A member of VLAN 1, this PC can only communicate with Server 2 
and PC 5. 

PC 4 

A member of VLAN 3, this PC can only communicate with Server 1 
and Server 2. 

PC 5 

A member of both VLAN 1 and VLAN 2, this PC has an Alteon ACE¬ 
nic Gigabit Ethernet Adapter installed. It is able to communicate with 
Server 2 via VLAN 1 and to PC 1 and PC 2 via VLAN 2. The switch 
port to which it is connected is configured for both VLAN 1 and 

VLAN 2 and has tagging turned on. 


NOTE — VLAN tagging is only required on ports that are connected to other Alteon Web 
switches or on ports that connect to tag-capable end-stations, such as servers with Alteon 
ACEnic Gigabit Ethernet Adapters. 
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Example 2: Parallel Links with VLANs 


ACEswitch 180 

10/100/10000 Mbps Ethernet Server Switch 

sH 2 §B 3 §B j sB 5 §B" sB 7 §B s 


A 


H gUBBU 9 


Gigabit Ethernet Trunk #1 
VLAN #10, VLAN #22 


ACEswitch WO 

10/100/10000 Mbps Ethernet Servei 

!H 2 IB 3 §H J §H 5 sB" §H 7 iH 1 




Gigabit Ethernet Trunk #2 
VLAN #32, VLAN #109 



Gigabit 

Powered 

m 







Figure 2-2 Example 2: Parallel Links with VLANs 


The following items describe the features of this example: 

■ Example 2 shows how it is possible, through the use of VLANs, to create configurations 
where there are multiple links between two switches, without creating broadcast loops. 

■ Two Alteon Web switches are connected with two different Gigabit Ethernet links. With¬ 
out VLANs, this configuration would create a broadcast loop, but the STP topology reso¬ 
lution process resolves parallel loop-creating links. 

■ To prevent broadcast loops, both switch-to-switch links are on different VLANs and, thus, 
are separated into their own broadcast domains. 

■ Ports 1 and 2 on both switches are on VLAN 10; ports 3 and 4 on both switches are on 
VLAN 22; Ports 5 and 6 on both switches are on VLAN 32; and port 9 on both switches is 
on VLAN 109. 

■ It is necessary to turn off Spanning Tree on at least one of the switch-to-switch links or, 
alternately, turned off in both switches. Spanning Tree executes on a per-network level, 
not a per-VLAN level. STP bridge Protocol Data Units (PDUs) will be transmitted out 
both connected Gigabit Ethernet ports and be interpreted by the connected switch that 
there is a loop to resolve. 

■ Spanning Tree is not VLAN-aware. Therefore, any VLAN configuration that might 
involve a parallel link from an STP perspective must be taken into account during network 
design. Alteon WebSystems recommends that you avoid topologies such as these, if at all 
possible. 
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Chapter 3 

Jumbo Frames 


To reduce host frame processing overhead, the Alteon WebSystems ACEnic adapters and Web 
switches, both running operating Web OS version 2.0 or later, can receive and transmit frames 
that are far larger than the maximum normal Ethernet frame. By sending one Jumbo frame 
instead of myriad smaller frames, the same task is accomplished with less processing. 

The switches and the ACEnic adapter support Jumbo frame sizes up to 9018 octets. These can 
be transmitted and received between ACEnic adapter-enabled hosts through the switch across 
any VLAN. 

Isolating Jumbo Frame Traffic using VLANs 


Jumbo frame traffic must not be used on a VLAN where there is any device that cannot process 
frame sizes larger than Ethernet maximum frame size. 

Additional VLANs can be configured on the adapters and switches to support non-Jumbo 
frame VLANs for servers and workstations that do not support extended frame sizes. End-sta¬ 
tions with an ACEnic adapters installed and attached to switches can communicate across both 
the Jumbo frame VLANs and regular frame VLANs at the same time. 

In the example illustrated in Figure 3-1 on page 46, the two servers can handle Jumbo frames 
but the two clients cannot; therefore Jumbo frames should only be enabled and used on the 
VLAN represented by the solid lines but not for the VLAN with the dashed lines. Jumbo 
frames are not supported on ports configured for half-duplex mode. 
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Server #1 


Server #2 


Normal Frame 
VLAN 



Normal Frame 
VLAN 
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Figure 3-1 Jumbo Frame VLANs 


Routing Jumbo Frames to Non-Jumbo 
Frame VLANs 


When IP routing is used to route traffic between VLANs, the switch will fragment Jumbo UDP 
datagrams when routing from a Jumbo frame VLAN to a non-Jumbo frame VLAN. The result¬ 
ing Jumbo frame to regular frame conversion makes implementation even easier. 
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Port Trunking 


This chapter provides configuration background and examples for trunking multiple ports 
together: 

■ “Port Trunking Overview” on page 47 

■ “Port Trunking Example” on page 49 

Port Trunking Overview 


Trunk groups can provide super-bandwidth, multi-link connections between Alteon Web 
switches or other trunk-capable devices. A trunk group is a group of ports that act together, 
combining their bandwidth to create a single, larger virtual link. 
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Figure 4-1 Port Trunk Group 


When using port trunk groups between two Alteon Web switches, for example, the network 
administrator can create a virtual link between the switches operating up to six Gigabits per 
second, depending on how many physical ports are combined. The switch supports up to four 
trunk groups per switch, each with two to six links. 

Trunk groups are also useful for connecting an Alteon Web switch to third-party devices that 
support link aggregation, such as Cisco routers and switches with EtherChannel technology 
(not ISL trunking technology) and Sun's Quad Fast Ethernet Adapter. Alteon WebSystems’ 
trunk group technology is compatible with these devices when they are configured manually. 
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Statistical Load Distribution 

Network traffic is statistically load balanced between the ports in a trunk group. The Web OS- 
powered switch uses both the Layer 2 MAC address and Layer 3 IP address information 
present in each transmitted frame for determining load distribution. 

The addition of Layer 3 IP address examination is an important advance for traffic distribution 
in trunk groups. In some port trunking systems, only Layer 2 MAC addresses are considered in 
the distribution algorithm. Each packet’s particular combination of source and destination 
MAC addresses results in selecting one line in the trunk group for data transmission. If there 
are enough Layer 2 devices feeding the trunk lines, then traffic distribution becomes relatively 
even. In some topologies, however, only a limited number of Layer 2 devices (such as a hand¬ 
ful of routers and servers) feed the trunk lines. When this occurs, the limited number of MAC 
address combinations encountered results in a lopsided traffic distribution, which can reduce 
the effective combined bandwidth of the trunked ports. 

By adding Layer 3 IP address information to the distribution algorithm, a far wider variety of 
address combinations is seen. Even with just a few routers feeding the trunk, the normal 
source/destination IP address combinations (even within a single LAN) can be widely varied. 
This results in a wider statistical load distribution and maximizes the use of the combined 
bandwidth available to trunked ports. 

Built-In Fault Tolerance 

Since each trunk group is comprised of multiple physical links, the trunk group is inherently 
fault tolerant. As long as one connection between the switches is available, the trunk remains 
active. 

Statistical load balancing is maintained whenever a port in a trunk group is lost or returned to 
service. 
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Port Trunking Example 


In this example, three ports will be trunked between two Alteon Web switches. 

Prior to configuring each switch in this example, you must connect to the appropriate switch’s 
Command Line Interface (CLI) as the administrator. 


NOTE — For details about accessing and using any of the menu commands described in this 
example, see the Web OS Command Reference. 


1. Connect the switch ports that will be involved in the trunk group. 

Switch #1 


Switch #2 
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Figure 4-2 Port Trunk Group Configuration Example 


2. On Switch 1, define a trunk group. 


>> # /cfg/trunk 1 

>> Trunk group 1# add 2 
>> Trunk group 1# add 4 
>> Trunk group 1# add 5 
>> Trunk group 1# ena 

(Select trunk group 1) 

(Add port 2 to trunk group 1) 

(Add port 4 to trunk group 1) 

(Add port 5 to trunk group 1) 

(Enable trunk group 1) 

On Switch 1, apply and verify the configuration. 


» Trunk group 1# apply 

(Make your changes active) 

» Trunk group 1# cur 

(View current trunking configuration) 

Examine the resulting information. If any settings are incorrect, make the appropriate changes. 

On Switch 1, save your new configuration changes. 

>> Trunk group 1# save 

(Save for restore after reboot) 
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5. On Switch 2, repeat the process. 


>> 

# /cfg/trunk 3 


(Select trunk group 3) 

>> 

Trunk 

group 

3# 

add 4 

(Add port 4 to trunk group 3) 

>> 

Trunk 

group 

3# 

add 6 

(Add port 6 to trunk group 3) 

>> 

Trunk 

group 

3# 

add 9 

(Add port 9 to trunk group 3) 

>> 

Trunk 

group 

3# 

ena 

(Enable trunk group 3) 

>> 

Trunk 

group 

3# 

apply 

(Make your changes active) 

>> 

Trunk 

group 

3# 

cur 

(View current trunking configuration) 

>> 

Trunk 

group 

3# 

save 

(Save for restore after reboot) 


Trunk group 1 (on Switch 1) is now connected to trunk group 3 (on Switch 2). 


NOTE — In this example, two Alteon Web switches are used. If a third-party device supporting 
link aggregation is used (such as Cisco routers and switches with EtherChannel technology or 
Sun’s Quad Fast Ethernet Adapter), trunk groups on the third-party device should be config¬ 
ured manually. Connection problems could arise when using automatic trunk group negotia¬ 
tion on the third-party device. 


6. Examine the trunking information on each switch. 

>> /info/trunk (View trunking information) 

Information about each port in each configured trunk group will be displayed. Make sure that 
trunk groups consist of the expected ports and that each port is in the expected state. 

The following restrictions apply: 

■ Any physical switch port can belong to only one trunk group. 

■ Up to four ports can belong to the same trunk group. 

■ Best performance is achieved when all ports in any given trunk group are configured for 
the same speed. 

■ Trunking from non-Alteon WebSystems devices must comply with Cisco® EtherChannel® 
technology. 
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Chapter 5 

Secure Switch Management 


To limit access to the switch’s Management Processor without having to configure filters for 
each switch port, you can set a source IP address (or range) that will be allowed to connect to 
the switch IP interface through Telnet, SSH, SNMP, or the Web OS Browser-Based Interface 
(BBI). This will also help prevent spoofing or attacks on the switch’s TCP/IP stack. The fol¬ 
lowing sections are addressed in this chapter: 

■ “Setting Allowable Source IP Address Ranges” on page 51 

■ “Secure Switch Management” on page 52 

■ “RADIUS Authentication and Authorization” on page 54 

■ “Secure Shell and Secure Copy” on page 58 

This section discusses the use of secure tunnels so that the data on the network is 
encrypted and secured for messages between a remote administrator and the switch. 

Setting Allowable Source IP Address 
Ranges 


The allowable management IP address range is configured using the system mnet and mmask 
options available on the Command Line Interface (CLI) System Menu (/cf g/sys). 


NOTE — The mnet and mmask commands in the /cfg/sib/adv menu are used for a differ¬ 
ent purpose. 


When an IP packet reaches the Management Processor, the source IP address is checked 
against the range of addresses defined by mnet and mmask. If the source IP address of the host 
or hosts are within this range, they are allowed to attempt to log in. Any packet addressed to a 
switch IP interface with a source IP address outside this range is discarded silently. 
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Example: Assume that the mnet is set to 192.192.192.0 and the mmask is set to 
255.255.255.128. This defines the following range of allowed IP addresses: 192.192.192.1 to 
192.192.192.127. 

■ A host with a source IP address of 192.192.192.21 falls within the defined range and 
would be allowed to access the switch Management Processor. 

■ A host with a source IP address of 192.192.192.192 falls outside the defined range and is 
not granted access. To make this source IP address valid, you would need to shift the host 
to an IP address within the valid range specified by the mnet and mmask or modify the 
mnet to be 192.192.192.128 and the mmask to be 255.255.255.128. This would put the 
192.192.192.192 host within the valid range allowed by the mnet and mmask 
(192.192.192.128-255). 


NOTE — When the mnet and mmask Management Processor filter is applied. Routing Inter¬ 
face Protocol (RIP) updates received by the switch will be discarded if the source IP address of 
the RIP packet(s) falls outside the specified range. You can correct this by configuring static 
routes. 


Secure Switch Management 


Secure switch management is needed for environments that perform significant management 
functions across the Internet. The following are some of the functions for secured manage¬ 
ment: 

■ Authentication of remote administrators 

Authentication is the action of determining and verifying who the administrator is; it usu¬ 
ally involves a name and a password. The password can be either a fixed password or a 
challenge-response query. 

■ Authorization of remote administrators 

Once an administrator has been authenticated, authorization is the action of determining 
what that user is allowed to do. Authorization does not merely provide yes or no answers 
but may also customize the service for a particular administrator. 

■ Encryption of management information exchanged between the remote administrator and 
the switch 

Examples of protocols to encrypt management information are SSH (Secure Shell) and 
SCP (Secure Copy). 
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Authentication and Authorization 


NOTE — While authentication and authorization (AA) protocols and servers are designed to 
authenticate remote dial-up users (in addition to authorizing remote access capabilities to 
users), this overview is focused on using the AA model to authenticate and authorize remote 
administrators for managing a switch. 


The AA model is based on a client/server model. The Remote Access Server (RAS)—the 
switch—is a client to the back-end database server. A remote user (the remote administrator) 
interacts only with the RAS, not the back-end server and database. 

Two prominent AA protocols used to control dial-up access into networks are Cisco's 
TACACS+ (Terminal Access Controller Access Control System) and Livingston Enterprise's 
RADIUS (Remote Authentication Dial-In User Service). Web OS 9.0 supports only the 
RADIUS authentication method. 

Requirements 

The following components are required for authorization and authentication: 

■ A remote administrator 

■ The Web switch with authentication and authorization protocol support, acting as a client 
in the AA model 

■ A back-end authentication and authorization server that performs the following functions 

□ Authenticates remote administrators 

□ Checks the remote administrator's authorization to access the switch 

□ Optionally, tracks and logs the administrator's activity while logging on 

■ An AA database that contains information about authorized administrators and their spe¬ 
cific capabilities and privileges 
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RADIUS Authentication and Authorization 


RADIUS is an access server authentication, authorization, and accounting protocol used to 
secure remote access to networks and network services against unauthorized access. 

RADIUS consists of three components: 

■ A protocol with a frame format that utilizes UDP over IP (based on RFC 2138) 

■ A centralized server that stores all the user authorization information 

■ A client, in this case, the switch 

The operation of RADIUS authentication and authorization protocol is based on the AA model 
described previously. The switch—acting as the RADIUS client—will communicate to the 
RADIUS server to authenticate and authorize a remote administrator using the protocol defini¬ 
tions specified in RFC 2138. Transactions between the client and RADIUS server are authenti¬ 
cated through the use of a shared secret, which is never sent over the network. In addition, the 
remote administrator passwords are sent encrypted between the RADIUS client (the switch) 
and the back-end RADIUS server. 


1. Remote administrator connects to 
switch and provides user name 
and password 


Internet 



2. Using Authentication/Authorization 
protocol, the switch sends request 
to authentication server 



Authentication 

Servers 


Alteon Web Switch 


4. Using RADIUS protocol, 3. 
the authentication server 
instructs the switch to 
grant or deny admim access 


Authentication server 
checks request against 
the user ID database 


Figure 5-1 Authentication and Authorization: How It Works 
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RADIUS Authentication Features in Web OS 

The following Radius Authentication features are supported in Web OS: 

■ Supports RADIUS client on the switch, based on the protocol definitions in RFC 2138 

■ Enables/disables support of RADIUS authentication and authorization 

■ The default disables the use of RADIUS for authentication and authorization. 

■ Allows RADIUS secret password up to 32 bytes and less than 16 octets 

■ Supports secondary authentication server so that when the primary authentication server 
is unreachable, the switch can send client authentication requests to the secondary authen¬ 
tication server 

Use the /cfg/sys/radius/cur command to show the currently active RADIUS 
authentication server. 

■ Supports user-configurable RADIUS server retry and time-out values 
The parameters are: 

□ Time-out value =1-10 seconds 

□ Retries = 1-3 

The switch will time out if it does not receive a response from the RADIUS server in 1-3 
seconds. The switch will also automatically retry connecting to the RADIUS server before 
it declares the server down. 

■ Supports user-configurable RADIUS application port 
The default is 1645/UDP based on RFC 2138. 

■ Allows network administrator to define privileges for one or more specific users to access 
the switch at the RADIUS user database 

■ SecurlD is supported if the RADIUS server can do an ACE/Server client proxy. The pass¬ 
word is the PIN number, plus the token code of the securlD card 
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Web Switch User Accounts 

The user accounts listed in Table 5-1 can be defined in the RADIUS server dictionary file. 


Table 5-1 User Access Levels 


User Account 

Description and Tasks Performed 

Password 

User 

The User has no direct responsibility for switch management. 
He/she can view all switch status information and statistics but 
cannot make any configuration changes to the switch. 

user 

SLB Operator 

The SLB Operator manages Web servers and other Internet 
services and their loads. In addition to being able to view all 
switch information and statistics, the SLB Operator can 
enable/disable servers using the SLB operation menu. 

slboper 

Layer 4 Opera¬ 
tor 

The Layer 4 Operator manages traffic on the lines leading to 
the shared Internet services. This user currently has the same 
access level as the SLB operator. This level is reserved for 
future use, to provide access to operational commands for 
operators managing traffic on the line leading to the shared 
Internet services. 

14oper 

Operator 

The Operator manages all functions of the switch. In addition 
to SLB Operator functions, the Operator can reset ports or 
the entire switch. 

oper 

SLB Adminis¬ 
trator 

The SLB Administrator configures and manages Web servers 
and other Internet services and their loads. In addition to SLB 
Operator functions, the SLB Administrator can configure 
parameters on the SLB menus, with the exception of not 
being able to configure filters or bandwidth management. 

slbadmin 

Layer 4 
Administrator 

The Layer 4 Administrator configures and manages traffic on 
the lines leading to the shared Internet services. In addition to 
SLB Administrator functions, the Layer 4 Administrator can 
configure all parameters on the SLB menus, including filters 
and bandwidth management. 

14admin 

Administrator 

The super-user Administrator has complete access to all 
menus, information, and configuration commands on the 
switch, including the ability to change both the user and 
administrator passwords. 

admin 
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When the user logs in, the switch authenticates his/her level of access by sending the RADIUS 
access request, that is, the client authentication request, to the RADIUS authentication server. 

If the remote user is successfully authenticated by the authentication server, the switch will 
verify the privileges of the remote user and authorize the appropriate access. When both the 
primary and secondary authentication servers are not reachable, the administrator has an 
option to allow backdoor access via the console only or console and telnet access. The default 
is disable for telnet access and enable for console access. 

All user privileges, other than those assigned to the Administrator, have to be defined in the 
RADIUS dictionary. The file name of the dictionary is RADIUS vendor-dependent. The fol¬ 
lowing user privileges are Alteon WebSystems proprietary definitions. 


Table 5-2 Alteon WebSystems User Access Levels 


User Name/Access 

User-Service-Type 

Value 

User 

Vendor-supplied 

255 

SLB Operator 

Vendor-supplied 

254 

Layer 4 Operator 

Vendor-supplied 

253 

Operator 

Vendor-supplied 

252 

SLB Administrator 

Vendor-supplied 

251 

Layer 4 Administrator 

Vendor-supplied 

250 
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Secure Shell and Secure Copy 


Although a remote network administrator can manage the configuration of an Alteon Web 
switch via Telnet, this method does not provide a secure connection. Using Secure Shell (SSH) 
and Secure Copy (SCP), messages between a remote administrator and the switch use secure 
tunnels so that the data on the network is encrypted and secured. Figure 5-1 on page 54 illus¬ 
trates secure switch management. 


NOTE — SSH/SCP features are configured via the console port, using the CLI. However, SCP 
putcfg and TFTP getcfg can also change the SSH/SCP configuration.When SSH is 
enabled, SCP is also enabled. 


SSH is a protocol that enables a remote administrator to log securely into another computer 
over a network to execute management commands. All the data sent over the network using 
SSH is encrypted and secured. Using SSH gives administrators an alternate way to manage the 
switch, one that provides strong security. 

SCP is typically used to copy files securely from one machine to another. SCP uses SSH for 
encryption of data on the network. On an Alteon Web switch, SCP is used to download and 
upload the switch configuration via secure channels. 

The benefits of using SSH and SCP are listed below: 

■ Authentication of remote administrators 
Identifying the administrator using Name/Password 

■ Authorization of remote administrators 

Determining the permitted actions and customizing service for individual administrators 

■ Encryption of management messages 

Encrypting messages between the remote administrator and switch 

■ Secure copy support 


NOTE — The Web OS implementation of SSH is based on SSH version 1.5 and supports SSH- 
1.5-1.x.xx. SSH clients of other versions (especially version 2) will not be supported. The fol¬ 
lowing SSH clients have been tested: 

■ SSH 1.2.23 and SSH 1.2.27 for Linux (freeware) 

■ SecureCRT 3.0.2 and SecureCRT 3.0.3 for Windows NT (Van Dyke Technologies, Inc.) 

■ F-Secure SSH 1.1 for Windows (Data Fellows) 
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NOTE — The maximum number of simultaneous Telnet/SSH/SCP connections is four. 
The /cfg/sys/radius/telnet command also applies to SSH/SCP connections. 


Encryption of Management Messages 

The supported encryption and authentication methods for both SSH and SCP are listed below: 

Server Host Authentication: Client RSA authenticates the switch at the beginning of 

every connection. 

Key Exchange: RSA 

Encryption: 3DES-CBC, DES 

User Authentication: Local password authentication, RADIUS, SecurlD (via 

RADIUS, for SSH only—does not apply to SCP) 

SCP Services 


NOTE — Administrator privileges are required to perform SCP commands. Set the SCP admin 
password (this password must be different from the admin password). 


The following SCP commands are supported in this service. These commands are entered 
using the CLI on the client that is running the SCP application: 

■ getcf g is used to download the switch’s configuration to the remote host via SCP. 

■ putcf g is used to upload the switch’s configuration from a remote host to the switch; the 
di f f command will be automatically executed at the end of putcf g to notify the remote 
client of the difference between the new and the current configurations. 

■ putcf g_apply will run the apply command after the putcf g is done. 

■ putcf g_apply_save saves the new configuration to the flash after putcf g_apply 
is done. 

The putcf g_apply and putcf g_apply_save commands are provided because extra 
apply and save commands are usually required after a putcf g; however, a SCP session is 
not in an interactive mode at all. 
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RSA Host and Server Keys 

To support the SSH server feature, two sets of RSA keys (host and server keys) are required. 
The host key is 1024 bits and is used to identify the Web switch. The server key is 768 bits and 
is used to make it impossible to decipher a captured session by breaking into the Web switch at 
a later time. 

When the SSH server is first enabled and applied, the switch will automatically generate the 
host and server keys and will then store them into the FLASH memory. 


NOTE — The Web switch will perform only one session of key/cipher generation at a time. 
Thus, an SSH/SCP client will not be able to log in if the switch is performing key generation at 
that time, or if another client has logged in immediately prior. Also, key generation will fail if 
an SSH/SCP client is logging in at that time. 


■ To generate a host key: 


>> # /cfg/sys/sshd/hkeygen 


■ To generate a server key: 


» # /cfg/sys/sshd/skeygen 


Again, the host and server key are automatically stored in FLASH memory when generated. 


NOTE — For security reasons, the SSHD menu options are available via the console port only 
and not via Telnet, SNMP, or the Browser-Based Interface (BBI). 


When the switch reboots, it will retrieve the host and server keys from the flash. If these two 
keys are not available in the flash and if the SSH server feature is enabled, the switch will auto¬ 
matically generate them during the system reboot. 

The switch can also automatically regenerate the RSA server key. To set the interval of RSA 
server key autogeneration, use this command: 


>> # /cfg/sys/sshd/intrval <nwnber of hours (0-24 )> 


where the number of hours must range between 0-24, and a value of 0 denotes that RSA server 
key autogeneration is disabled. When greater than 0, the switch will autogenerate the RSA 
server key every specified interval; however, RSA server key generation will be skipped if the 
switch is busy doing other key or cipher generation when the timer expires. 
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Radius Authentication 

SSH/SCP is integrated with RADIUS authentication. After the RADIUS server is enabled on 
the switch, all subsequent SSH authentication requests will be redirected to the specified 
RADIUS servers for authentication. The redirection is transparent to the SSH clients. 

SecurlD Support 

SSH/SCP can also work with SecurlD, a token card-based authentication method. The use of 
SecurlD requires the interactive mode during login, which is not provided by the SSH connec¬ 
tion. 


NOTE — There is no SNMP or Browser-Based Interface (BBI) support for SecurlD because the 
SecurlD server, ACE, is a one-time password authentication and requires an interactive ses¬ 
sion. 


To log in using SSH without difficulties, you need to use a special username, “ace,” to log in 
and bypass the SSH authentication. After an SSH connection is established, you will then be 
prompted to enter the username and password (the SecurlD authentication is being performed 
now). You will need to provide your actual username and the token in your SecurlD card as a 
regular Telnet user would do in order to log in. 

To use SCP, you need to use the SCP-only administrator’s password (that is, the scpadm 
option under the /cfg/sys/sshd menu) to bypass the checking of SecurlD. Alternately, 
you can configure a regular administrator with a fixed password in the RADIUS server if it can 
be supported. A regular administrator with a fixed password in the RADIUS server can per¬ 
form both SSH and SCP with no additional authentication required. 

A SCP-only administrator’s password is typically used when SecurlD is used. For example, it 
can be used in an automation program (in which the tokens of SecurlD are not available) to 
back up (download) the switch configurations each day. 


NOTE — The SCP-only administrator’s password must be different from the regular administra¬ 
tor’s password. If the two passwords are the same, the administrator using that password will 
not be allowed to log in as a SSH user because the switch will recognize him as the SCP-only 
administrator and only allow the administrator access to SCP commands. 
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Configuring SSH/SCP 


NOTE — SSH/SCP parameters can be configured only via the console port, using the CLI. The 
switch SSH daemon uses TCP port 22 only and is not configurable. 


To enable or disable the SSH/SCP feature, use the following commands: 


>> # /cfg/sys/sshd/on 

(Turn SSH/SCP on) 

>> # /cfg/sys/sshd/off 

(Turn SSH/SCP off) 


To set the interval of RSA server key autogeneration, use this command: 


>> # /cfg/sys/sshd/intrval <number of hours (0-24)> 


where the number of hours must range between 0-24, and a value of 0 denotes that RSA server 
key autogeneration is disabled. When greater than 0, the switch will auto-generate the RSA 
server key every interval specified; however, RSA server key generation will be skipped if the 
switch is busy doing other key or cipher generation when the timer expires. 

To enable or disable the SCP apply and save (i.e., SCP putcfg_apply and 
putcf g_apply_save commands), use these commands: 


>> # /cfg/sys/sshd/ena (Enable SSH/SCP apply and save) 

» # /cfg/sys/sshd/dis (Disable SSH/SCP apply and save) 


The following commands are useful for obtaining information about the current SSH/SCP- 
related configuration: 


» # /cfg/sys/sshd/cur 

(View current SSH/SCP settings) 

» # diff 

(View pending changes) 


To apply the pending changes from the new configuration, use this command: 


>> # apply 


NOTE — If SSH/SCP is enabled and an apply command is issued, the switch will automati¬ 
cally generate the RSA host and server keys if they are not available. It will take several min¬ 
utes to complete this process. 
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To save the current configuration to FLASH, use this command: 


» # save 


Usually, there will be no need to generate manually the RSA host and server keys. However, 
you may still do so by using the following commands: 


» # /cfg/sys/sshd/hkeygen 

(Generates the host key) 

» # /cfg/sys/sshd/skeygen 

(Generates the server key) 


NOTE — These two commands will take effect immediately without the need of an apply 
command being issued. 


Some Supported Client Commands 


NOTE — Up to four simultaneous Telnet/SSH/SCP connections are supported on a switch. 


■ To log in to the switch: 

ssh <switch IP address> orssh-1 <username> <switch IP address> 

■ To download the switch configuration using SCP: 

scp <switch IP ciddress> : getcfg <IocaI filename> 

■ To upload the configuration to the switch: 

scp <local filename> <switch IP address> :putcfg 
Some examples are listed below: 


» 

# 

ssh 

205.178.15. 

157 


» 

# 

ssh 

-1 dleu 205 

.178.15.157 


» 

# 

scp 

205.178.15. 

157:getcfg 

ad4.cfg 

» 

# 

scp 

ad4.cfg 205 

.178.15.157 

:putcfg 


where 205.178.15.157 is the IP address of the example switch. 

Please also note that apply and save commands are still needed after the last command 
(scp ad4 .cfg 205.178.15.157: putcf g) is issued. Or, instead, you can use the fol¬ 
lowing commands: 


>> # scp ad4.cfg 205.178.15.157:putcfg_apply 
» # scp ad4.cfg 205.178.15.157:putcfg_apply_save 
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Part 2: Web Switching 
Fundamentals 


Internet traffic consists of myriad services and applications which use the Internet Protocol 
(IP) for data delivery. IP, however, is not optimized for all the various applications. Web 
switching goes beyond IP and makes intelligent switching decisions based on the application 
and its data. This sections details the following fundamental Web switching features: 

■ Server Load Balancing 

■ Filtering 

■ Application Redirection 

■ Virtual Matrix Architecture 

■ Health Checking 

■ High Availability 
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Chapter 6 

Server Load Balancing 


Server Load Balancing (SLB) allows you to configure the Alteon Web switch to balance user 
session traffic among a pool of available servers that provide shared services. The following 
sections in this chapter describe how to configure and use SLB: 

■ “Understanding Server Load Balancing” on page 68. This section discusses the benefits of 
server load balancing and how it works. 

■ “Implementing Basic Server Load Balancing” on page 71. This section discusses how 
implementing SLB provides reliability, performance, and ease of maintenance on your 
network. 

□ “Network Topology Requirements” on page 72. This section provides key require¬ 
ments to consider before deploying server load balancing. 

□ “Configuring Server Load Balancing” on page 74. 

□ “Additional Server Load Balancing Options” on page 78. 

■ “Extending SLB Topologies” on page 85. This section discusses proxy IP addresses, map¬ 
ping a virtual port to real ports, monitoring real server ports, and delayed binding. 

■ “Load Balancing Special Services” on page 99. This section discusses load balancing 
based on special services, such as source IP addresses, FTP, RTSP, WAP, IDS, and WAN 
link. 

For additional information about the SLB feature, see your Web OS Command Reference. 
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Understanding Server Load Balancing 


Benefits 

SLB benefits your network in a number of ways: 

■ Increased efficiency for server utilization and network bandwidth 

With SLB, your Alteon Web switch is aware of the shared services provided by your 
server pool and can then balance user session traffic among the available servers. Impor¬ 
tant session traffic gets through more easily, reducing user competition for connections on 
overutilized servers. For even greater control, traffic is distributed according to a variety 
of user-selectable rules. 

■ Increased reliability of services to users 

If any server in a server pool fails, the remaining servers continue to provide access to 
vital applications and data. The failed server can be brought back up without interrupting 
access to services. 

■ Increased scalability of services 

As users are added and the server pool’s capabilities are saturated, new servers can be 
added to the pool transparently. 

Identifying Your Network Needs 

SLB may be the right option for addressing these vital network concerns: 

■ A single server no longer meets the demand for its particular application. 

■ The connection from your LAN to your server overloads the server’s capacity. 

■ Your NT and UNIX servers hold critical application data and must remain available even 
in the event of a server failure. 

■ Your Web site is being used as a way to do business and for taking orders from customers. 
It must not become overloaded or unavailable. 

■ You want to use multiple servers or hot-standby servers for maximum server uptime. 

■ You must be able to scale your applications to meet client and LAN request capacity. 

■ You can’t afford to continue using an inferior load-balancing technique, such as DNS 
round robin or a software-only system. 
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How Server Load Balancing Works 

In an average network that employs multiple servers without server load balancing, each server 
usually specializes in providing one or two unique services. If one of these servers provides 
access to applications or data that is in high demand, it can become overutilized. Placing this 
kind of strain on a server can decrease the performance of the entire network as user requests are 
rejected by the server and then resubmitted by the user stations. Ironically, overutilization of key 
servers often happens in networks where other servers are actually available. 


The solution to getting the most from your servers is SLB. With this software feature, the 
switch is aware of the services provided by each server. The switch can direct user session traf¬ 
fic to an appropriate server, based on a variety of load-balancing algorithms. 
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Figure 6-1 Traditional Versus SLB Network Configurations 

To provide load balancing for any particular type of service, each server in the pool must have 
access to identical content, either directly (duplicated on each server) or through a back-end 
network (mounting the same file system or database server). 
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The Web switch, with SLB software, acts as a front-end to the servers, interpreting user session 
requests and distributing them among the available servers. Load balancing in Web OS 9.0 can 
be done in the following ways: 

■ Virtual server-based load balancing 

This is the traditional load balancing method. The switch is configured to act as a virtual 
server and is given a virtual server IP address (or range of addresses) for each collection of 
services it will distribute. Depending on your switch model, there can be as many as 256 
virtual servers on the switch, each distributing up to eight different services (up to a total 
of 2048 services). 

Each virtual server is assigned a list of the IP addresses (or range of addresses) of the real 
servers in the pool where its services reside. When the user stations request connections to 
a service, they will communicate with a virtual server on the switch. When the switch 
receives the request, it binds the session to the IP address of the best available real server 
and remaps the fields in each frame from virtual addresses to real addresses. 

IP, FTP, RTSP, IDS, and static session WAP are expamples of some of the services that use 
virtual servers for load balancing. 

■ Filtered-based load balancing 

A filter allows you to control the types of traffic permitted through the switch. Filters are 
configured to allow, deny, or redirect traffic according to the IP address, protocol, or Layer 
4 port criteria. In filtered-based load balancing, a filter is used to redirect traffic to a real 
server group. If the group is configured with more than one real server entry, redirected 
traffic is load balanced among the available real servers in the group. 

Firewalls, WAP with RADIUS snooping, IDS, and WAN links use redirection filters to 
load balance traffic. 

■ Content-based load balancing 

Content-based load balancing uses Layer 7 application data (such as URL, cookies, and 
Host Headers) to make intelligent load balancing decisions. 

URL-based load balancing, browser-smart load balancing, and cookie-based preferential 
load balancing are a few examples of content-based load balancing. 
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Implementing Basic Server Load Balancing 


Consider a situation where customer Web sites are being hosted by a popular Web hosting 
company and/or Internet Service Provider (ISP). The Web content is relatively static and is 
kept on a single NFS server for easy administration. As the customer base increases, the num¬ 
ber of simultaneous Web connection requests also increases. 



Figure 6-2 Web Hosting Configuration Without SLB 


Such a company has three primary needs: 


■ Increased server availability 

■ Server performance scalable to match new customer demands 

■ Easy administration of network and servers 



Alteon Web 
Switch 


Internet 


Web Host 
Routers 


Layer 2 
Switching 


Layer 2 
Switching 


Web Clients 


Layer 4 Switching & 
Server Load Balancing 


Web Server Farm 

A 


NFS Server 


Figure 6-3 Web Hosting with SLB Solutions 
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All of the above issues can be addressed by adding an Alteon Web switch with SLB software. 

■ Reliability is increased by providing multiple paths from the clients to the Web switch and 
by accessing a pool of servers with identical content. If one server fails, the others can take 
up the additional load. 

■ Performance is improved by balancing the Web request load across multiple servers. More 
servers can be added at any time to increase processing power. 

■ For ease of maintenance, servers can be added or removed dynamically, without interrupt¬ 
ing shared services. 

Network Topology Requirements 

When deploying SLB, there are a few key aspects to consider: 

■ In standard SLB, all client requests to a virtual server IP address and all responses from the 
real servers must pass through the switch, as shown in Figure 6-4. If there is a path between 
the client and the real servers that does not pass through the switch, the Web switch can be 
configured to proxy requests in order to guarantee that responses use the correct path (see 
“Proxy IP Addresses” on page 85). 



addresses must be used on the Server Pool #2 

Alteon Web switch 

Figure 6-4 SLB Client/Server Traffic Routing 

■ Identical content must be available to each server in the same pool. Either of these meth¬ 
ods can be used: 

□ Static applications and data are duplicated on each real server in the pool. 

□ Each real server in the pool has access to the same data through use of a shared file 
system or back-end database server. 
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■ Some services require that a series of client requests go to the same real server so that ses¬ 
sion-specific state data can be retained between connections. Services of this nature 
include Web search results, multi-page forms that the user fills in, or custom Web-based 
applications typically created using cgi-bin scripts. Connections for these types of ser¬ 
vices must be configured as persistent (see Chapter 16, “Persistence”) or must use the 
minmisses or hash metrics (see “Metrics for Real Server Groups” on page 80). 

■ Clients and servers can be connected through the same switch port. Each port in use on the 
switch can be configured to process client requests, server traffic, or both. You can enable 
or disable processing on a port independently for each type of Layer 4 traffic. 

□ Layer 4 client processing: Ports that are configured to process client request traffic 
provide address translation from the virtual IP to the real server IP address. 

□ Layer 4 server processing: Ports that are configured to process server responses to cli¬ 
ent requests provide address translation from the real server IP address to the virtual 
IP address. These ports require real servers to be connected to the Web switch directly 
or through a hub, router, or another switch. 


NOTE — Switch ports configured for Layer 4 client/server processing can simultaneously pro¬ 
vide Layer 2 switching and IP routing functions. 


Consider the following network topology: 
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Figure 6-5 Example Network for Client/Server Port Configuration 


In Ligure 6-5, the switch load balances traffic to a Web server pool and to a Domain Name 
System (DNS) server pool. The switch port connected to the Web server pool (port 2) is 
asked to perform both server and client processing. 

Some topologies require special configuration. Lor example, if clients were added to Switch B 
as shown in figure 6-5, these clients could not access the Web server pool using SLB services, 
except through a proxy IP address that is configured on port 2 of the Alteon Web switch. 
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Configuring Server Load Balancing 

This section describes the steps for configuring an SLB Web hosting solution. In the following 
procedure, many of the SLB options are left to their default values. See “Additional Server 
Load Balancing Options” on page 78 for more options. 

The following is required prior to configuration: 

■ You must be connected to the switch Command Line Interface (CLI) as the administrator. 

■ The SLB software must be enabled. 


NOTE — For details about any of the menu commands described in this example, see your Web 
OS 9.0 Command Reference. 


1. Assign an IP address to each of the real servers in the server pool. 

The real servers in any given real server group must have an IP route to the switch that per¬ 
forms the SLB functions. This IP routing is most easily accomplished by placing the switches 
and servers on the same IP subnet, although advanced routing techniques can be used as long 
as they do not violate the topology rules outlined in “Network Topology Requirements” on 
page 72. 

For this example, the three Web-host real servers have been given the following IP addresses 
on the same IP subnet: 

Table 6-1 Web Host Example: Real Server IP Addresses 


Real Server 

IP address 

Server A 

200.200.200.2 

Server B 

200.200.200.3 

Server C 

200.200.200.4 


NOTE — An imask option can be used to define a range of IP addresses for real and virtual 
servers (see “IP Address Ranges Using imask” on page 79). 
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2. Define an IP interface on the switch. 

The switch must have an IP route to all of the real servers that receive Web switching services. 
For SLB, the switch uses this path to determine the level of TCP/IP reach of the real servers. 

To configure an IP interface for this example, enter these commands from the CLI: 


>> 

# 

/cfg/ip/if 

1 

(Select IP interface 1) 

>> 

IP 

Interface 

1# addr 200.200.200.100 

(Assign IP address for the interface) 

>> 

IP 

Interface 

1# ena 

(Enable IP interface 1) 


NOTE — The IP interface and the real servers must belong to the same VLAN, if they are in the 
same subnet. This example assumes that all ports and IP interfaces use default VLAN 1, 
requiring no special VLAN configuration for the ports or IP interface. 


3. Define each real server. 

For each real server, you must assign a real server number, specify its actual IP address, and 
enable the real server. For example: 


» 

IP Interface 

i# 

/cfg/slb/real 1 

f Server A is real server 1) 

» 

Real 

server 

i# 

rip 200.200.200.2 

(Assign Server A IP address) 

» 

Real 

server 

i# 

ena 

(Enable real server 1) 

» 

Real 

server 

i# 

../real 2 

(Setyer B is real server 2) 

» 

Real 

server 

2# 

rip 200.200.200.3 

(Assign Setyer B IP address) 

» 

Real 

server 

2# 

ena 

(Enable real server 2) 

» 

Real 

server 

2# 

../real 3 

(Setyer C is real sen’er 3) 

» 

Real 

server 

3# 

rip 200.200.200.4 

(Assign Sen’er C IP address) 

» 

Real 

server 

3# 

ena 

(Enable real sen’er 3) 


4. Define a real server group and add the three real servers to the service group. 


» 

Real 

server 

3# /cfg/ 

slb/group 1 

(Select real server group 1) 

» 

Real 

server 

group 

i# 

add 

1 

(Add real sen’er 1 to group 1) 

» 

Real 

server 

group 

i# 

add 

2 

(Add real sen’er 2 to group 1) 

» 

Real 

server 

group 

i# 

add 

3 

(Add real sen’er 3 to group 1) 
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5. Define a virtual server. 

All client requests will be addressed to a virtual IP address on a virtual server defined on the 
switch. Clients acquire the virtual IP address through normal DNS resolution. In this example, 
HTTP is configured as the only service running on this virtual server, and this service is associ¬ 
ated with the real server group. For example: 


>> 

Real server group 

1# /cfg/slb/virt 1 

(Select virtual server 1) 

>> 

Virtual 

server 

i# 

vip 200.200.200.1 

(Assign a virtual server IP address) 

>> 

Virtual 

server 

i# 

ena 

(Enable the virtual ser\>er) 

>> 

Virtual 

server 

i# 

service http 

(Select the HTTP service menu) 

>> 

Virtual 

server 

i 

http Service# group 1 

(Associate virtual port to real group) 


NOTE — This configuration is not limited to HTTP Web service. Other TCP/IP services can be 
configured in a similar fashion. For a list of other well-known services and ports, see “Well- 
Known Application Ports” on page 78. 

6. Define the port settings. 

In this example, the following ports are being used on the Web switch: 

Table 6-2 Web Host Example: Port Usage 


Port 

Host 

L4 Processing 

1 

Server A serves SLB requests. 

Server 

2 

Server B serves SLB requests. 

Server 

3 

Server C serves SLB requests. 

Server 

4 

Back-end NFS server provides centralized Web content for all three 
real servers. This port does not require Web switching features. 

None 

5 

Client router A connects the switch to the Internet where client 
requests originate. 

Client 

6 

Client router B connects the switch to the Internet where client 
requests originate. 

Client 
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The ports are configured as follows: 


>> 

Virtual 

server 1# /cfg/slb/port 1 

(Select physical switch port 1) 

>> 

SLB 

port 

1# 

server ena 

(Enable sen’er processing on port 1) 

>> 

SLB 

port 

1# 

../port 2 

(Select physical switch port 2) 

>> 

SLB 

port 

2# 

server ene 

(Enable sen’er processing on port 2) 

>> 

SLB 

port 

2# 

../port 3 

(Select physical switch port 3) 

>> 

SLB 

port 

3# 

server ena 

(Enable sen’er processing on port 3) 

>> 

SLB 

port 

3# 

../port 5 

(Select physical switch port 5) 

>> 

SLB 

port 

5# 

client ena 

(Enable client processing on port 5) 

>> 

SLB 

port 

5# 

../port 6 

(Select physical switch port 6) 

>> 

SLB 

port 

6# 

client ena 

(Enable client processing on port 6) 


7. Enable, apply, and verify the configuration. 


» 

SLB port 

6# . . 

(Select the SLB Menu) 

» 

Layer 4# 

on 

(Turn Sen’er Load Balancing on) 

» 

Layer 4# 

apply 

(Make your changes active) 

» 

Layer 4# 

cur 

(View current settings) 


Examine the resulting information. If any settings are incorrect, make the appropriate changes. 

8. Save your new configuration changes. 


>> Layer 4# save 


(Save for restore after reboot) 


NOTE — You must apply any changes in order for them to take effect, and you must save 
changes if you wish them to remain in effect after switch reboot. 


9. Check the SLB information. 


» Layer 4# /info/slb/dump (View SLB information) 


Check that all SLB parameters are working according to expectation. If necessary, make any 
appropriate configuration changes and then check the information again. 
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Additional Server Load Balancing Options 

In the previous section (“Configuring Server Load Balancing” on page 74), many of the SLB 
options are left to their default values. The following configuration options can be used to cus¬ 
tomize SLB on your Web switch: 

■ Supported Services and Applications 

■ Disabling and Enabling Real Servers 

■ IP Address Ranges Using imask 

■ Health Checks for Real Servers 

■ Metrics for Real Server Groups 

■ Weights for Real Servers 

■ Connection Time-outs for Real Servers 

■ Maximum Connections for Real Servers 

■ Backup/Overflow Servers 

Supported Services and Applications 

Each virtual server can be configured to support up to eight services, limited to a total of 256 
services per switch. Using the /cfg/slb/virt <virtual server number> / service 
option, the following TCP/UDP applications can be specified: 


Table 6-3 Well-Known Application Ports 


Number TCP/UDP 
Application 

Number TCP/UDP 
Application 

Number TCP/UDP 
Application 

20 

ftp-data 

70 

gopher 

161 

snmp 

21 

ftp 

79 

finger 

162 

snmptrap 

22 

ssh 

80 

http 

179 

bgP 

23 

telnet 

109 

pop2 

194 

ire 

25 

smtp 

110 

pop3 

220 

imap3 

37 

time 

111 

sunrpc 

389 

ldap 

42 

name 

119 

nntp 

443 

https 

43 

whois 

123 

ntp 

520 

rip 

53 

domain 

143 

imap 

554 

rtsp 

69 

tftp 

144 

news 

1985 

hsrp 


NOTE — Load balancing some applications (such as FTP and RTSP) require special attention. 
See “Load Balancing Special Services” on page 99 for more information. 
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Disabling and Enabling Real Servers 

If you need to reboot a server, you must make sure that new sessions are not sent to the real 
server and that old sessions are not discarded. When the session count gets to zero, you may 
shut down the server. Use the following command to disable real servers: 


» # /oper/slb/dis <real server number> 


When maintenance is complete, use the following command to enable the real server: 


» # /oper/slb/ena <real server number> 


IP Address Ranges Using imask 

The imask option lets you define a range of IP addresses for the real and virtual servers config¬ 
ured under SLB. By default, the imask setting is 255.255.255.255, which means that each real 
and virtual server represents a single IP address. An imask setting of 255.255.255.0 would mean 
that each real and virtual server represents 256 IP addresses. Consider the following example: 

■ A virtual server is configured with an IP address of 172.16.10.1. 

■ Real servers 172.16.20.1 and 172.16.30.1 are assigned to service the virtual server. 

■ The imask is set to 255.255.255.0. 

If the client request was sent to virtual server IP address 172.16.10.45, the unmasked portion of 
the address (0.0.0.45) gets mapped directly to whichever real server IP address is selected by 
the SLB algorithm. Thus, the request would be sent to either 172.16.20.45 or 172.16.30.45. 

Health Checks for Real Servers 

Determining health for each real server is a necessary function for SLB. By default for TCP ser¬ 
vices, the switch checks health by opening a TCP connection to each service port configured as 
part of each service. For UDP services, the switch pings servers to determine their status. 

By default, the switch checks each service on each real server every two seconds. If the real 
server is busy processing connections, it may not respond to a health check. By default, if a ser¬ 
vice does not respond to four consecutive health checks, the switch declares the service unavail¬ 
able. As shown below, the health check interval and the number of retries can be changed: 


>> # /cfg/slb/real <real server number> 

(Select the real setyer) 

» Real server# 

inter 4 

(Check real setyer every 4 seconds) 

>> Real server# 

retry 6 

(Declare down after 6 checks fail) 


For more complex health-checking strategies, see Chapter 10, “Health Checking.” 


Alteon UkbSysXems Chapter 6: Server Load Balancing ■ 79 

050159A, May 2001 





Web OS 9.0 Application Guide 


Metrics for Real Server Groups 

Metrics are used for selecting which real server in a group will receive the next client connec¬ 
tion. The available metrics minmisses (minimum misses), hash, leastconns (least con¬ 
nections), roundrobin, bandwidth, and response (response time) are explained in 
detail below. The default metric is leastconns. 

To change a real server group metric to minmisses for example, enter: 


>> # /cfg/slb/group <group number> (Select the real server group) 

» Real server group# metric minmisses (Use minmisses metric) 


Minimum Misses 

The minmisses metric is optimized for Application Redirection. It uses IP address informa¬ 
tion in the client request to select a server. The specific IP address information used depends on 
the application: 

■ For Application Redirection, the client destination IP address is used. All requests for a 
specific IP destination address is sent to the same server. This metric is particularly useful 
in caching applications, helping to maximize successful cache hits. Best statistical load 
balancing is achieved when the IP address destinations of load-balanced frames are spread 
across a broad range of IP subnets. 

■ For SLB, the client source IP address and real server IP address are used. All requests 
from a specific client are sent to the same server. This metric is useful for applications 
where client information must be retained on the server between sessions. With this met¬ 
ric, server load becomes most evenly balanced as the number of active clients with differ¬ 
ent source or destination addresses increases. 

When selecting a server, the switch calculates a score for each available real server based on 
the relevant IP address information. The server that scores the highest is assigned the connec¬ 
tion. This metric attempts to minimize the disruption of persistency when servers are removed 
from service. This metric should be used only when persistence is a must. 


NOTE — The minmisses metric cannot be used for firewall load balancing, since the real 
server IP addresses used in calculating the score for this metric are different on each side of the 
firewall. 


80 ■ Chapter 6: Server Load Balancing 


Alteon ((^Systems 

050159A. May 2001 





Web OS 9.0 Application Guide 


Hash 

The hash metric uses IP address information in the client request to select a server. The spe¬ 
cific IP address information used depends on the application: 

■ For Application Redirection, the client destination IP address is used. All requests for a 
specific IP destination address will be sent to the same server. This is particularly useful 
for maximizing successful cache hits. 

■ For SLB, the client source IP address is used. All requests from a specific client will be 
sent to the same server. This option is useful for applications where client information 
must be retained between sessions. 

■ For FWLB, both the source and destination IP addresses are used to ensure that the two 
unidirectional flows of a given session are redirected to the same firewall. 

When selecting a server, a mathematical hash of the relevant IP address information is used as 
an index into the list of currently available servers. Any given IP address information will 
always have the same hash result, providing natural persistence, as long as the server list is sta¬ 
ble. However, if a server is added to or leaves the mix, then a different server might be 
assigned to a subsequent session with the same IP address information even though the original 
server is still available. Open connections are not cleared. 


NOTE — The hash metric provides more distributed load balancing than minmisses at any 
given instant. It should be used if the statistical load balancing achieved using minmisses is 
not as optimal as desired. If the load balancing statistics with minmisses indicate that one 
server is processing significantly more requests over time than other servers, consider using 
the hash metric. 


Least Connections 

With the leastconns metric, the number of connections currently open on each real server 
is measured in real time. The server with the fewest current connections is considered to be the 
best choice for the next client connection request. 

This option is the most self-regulating, with the fastest servers typically getting the most con¬ 
nections over time. 

Round Robin 

With the roundrobin metric, new connections are issued to each server in turn; that is, the 
first real server in the group gets the first connection, the second real server gets the next con¬ 
nection, followed by the third real server, and so on. When all the real servers in this group 
have received at least one connection, the issuing process starts over with the first real server. 
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Response Time 

The response metric uses real server response time to assign sessions to servers. The 
response time between the servers and the switch is used as the weighting factor. The switch 
monitors and records the amount of time it takes for each real server to reply to a health check 
to adjust the real server weights. The weights are adjusted so they are inversely proportional to 
a moving average of response time. In such a scenario, a server with half the response time as 
another server will receive a weight twice as large. 


NOTE — The effects of the response weighting apply directly to the real servers and are not 
necessarily confined to the real server group. When response time-metered real servers are also 
used in other real server groups that use the leastconns or roundrobin metrics, the 
response weights are applied on top of the leastconns or roundrobbin calculations 
for the affected real servers. Since the response weight changes dynamically, this can pro¬ 
duce fluctuations in traffic distribution for the real server groups that use the leastconns or 
roundrobin metrics. 


Bandwidth 

The bandwidth metric uses real server octet counts to assign sessions to a server. The switch 
monitors the number of octets sent between the server and the switch. Then, the real server 
weights are adjusted so they are inversely proportional to the number of octets that the real 
server processes during the last interval. 

Servers that process more octets are considered to have less available bandwidth than servers 
that have processed fewer octets. For example, the server that processes half the amount of 
octets over the last interval receives twice the weight of the other servers. The higher the band¬ 
width used, the smaller the weight assigned to the server. Based on this weighting, the subse¬ 
quent requests go to the server with the highest amount of free bandwidth. These weights are 
automatically assigned. 

The bandwidth metric requires identical servers with identical connections. 


NOTE — The effects of the bandwidth weighting apply directly to the real servers and are not 
necessarily confined to the real server group. When bandwidth-metered real servers are also 
used in other real server groups that use the leastconns or roundrobin metrics, the 
bandwidth weights are applied on top of the leastconns or roundrobbin calculations 
for the affected real servers. Since the bandwidth weight changes dynamically, this can pro¬ 
duce fluctuations in traffic distribution for the real server groups that use the leastconns or 
roundrobin metrics. 
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Weights for Real Servers 

Weights can be assigned to each real server. These weights bias load balancing to give the fast¬ 
est real servers a larger share of connections. Weight is specified as a number from 1 to 48. 
Each increment increases the number of connections the real server gets. By default, each real 
server is given a weight setting of 1. A setting of 10 would assign the server roughly 10 times 
the number of connections as a server with a weight of 1. To set weights, enter the following 
commands: 


» # /cfg/slb/real <real setyer number> (Select the real server) 

» Real server# weight 10 (10 times the number of connections) 


NOTE — Weights are not applied when using the hash or minmisses metrics. 


Connection Time-outs for Real Servers 

In some cases, open TCP/IP sessions might not be closed properly (for example, the switch 
receives the SYN for the session, but no FIN is sent). If a session is inactive for 10 minutes (the 
default), it is removed from the session table in the switch. To change the time-out period, 
enter the following: 


>> # /cfg/slb/real <real sen’er number> (Select the real setyer) 

» Real server# tmout 4 (Specify an even numbered interval) 


The example above would change the time-out period of all connections on the designated real 
server to four minutes. 

Maximum Connections for Real Servers 

You can set the number of open connections each real server is allowed to handle for SLB. To 
set the connection limit, enter the following: 


>> # /cfg/slb/real <real sen’er number> (Select the real setyer) 

» Real server# maxcon 1600 (Allow 1600 connections maximum) 


Values average from approximately 500 HTTP connections for slower servers to 1500 for 
quicker, multiprocessor servers. The appropriate value also depends on the duration of each 
session and how much CPU capacity is occupied by processing each session. Connections that 
use a lot of Java or CGI scripts for forms or searches require more server resources and thus a 
lower maxcon limit. You may wish to use a performance benchmark tool to determine how 
many connections your real servers can handle. 

When a server reaches its maxcon limit, the switch no longer sends new connections to the 
server. When the server drops back below the maxcon limit, new sessions are again allowed. 
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Backup/Overflow Servers 

A real server can backup other real servers and can handle overflow traffic when the maximum 
connection limit is reached. Each backup real server must be assigned a real server number and 
real server IP address. It must then be enabled. Finally, the backup must be assigned to each real 
server it will back up. The following defines real server 4 as a backup for real servers 1 and 2: 


>> 

# /cfg/slb/real 4 


(Select real sen’er 4 as backup) 

>> 

Real 

server 

4# 

rip 200.200.200.5 

(Assign backup IP address) 

>> 

Real 

server 

4# 

ena 


(Enable real sen’er 4) 

>> 

Real 

server 

4# 

/cfg/slb/real 

1 

(Select real sen’er 1) 

>> 

Real 

server 

1# 

backup 4 


(Real sen’er 4 is backup for 1) 

>> 

Real 

server 

1# 

/cfg/slb/real 

2 

(Select real sen’er 2) 

>> 

Real 

server 

2# 

backup 4 


(Real sen’er 4 is backup for 2) 


In a similar fashion, a backup/overflow server can be assigned to a real server group. If all real 
servers in a real server group fail or overflow, the backup comes online. 


» 

» 

# /cfg/slb/group <real sen’er group number> 
Real server group# backup r4 

(Select real sen’er group) 

(Assign real sen’er 4 as backup) 

Real server groups can also use another real server group for backup/overflow: 

>> 

# /cfg/slb/group <real sen’er group number> 

(Select real sen’er group) 

>> 

Real server group# backup g2 

(Assign real sen’er group 2 as 
backup) 
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Extending SLB Topologies 


For standard SLB, all client-to-server requests to a particular virtual server and all related 
server-to-client responses must pass through the same Web switch. In complex network topol¬ 
ogies, routers and other devices can create alternate paths around the Web switch managing 
SLB functions (see Figure 6-4 on page 72). Under such conditions, the Web switch with 
Web OS provides the following solutions: 

■ Proxy IP Addresses 

■ Mapping Ports 

■ Direct Server Interaction 

■ Delayed Binding 

Proxy IP Addresses 

In complex network topologies (see Figure 6-4 on page 72), SLB functions can be managed 
using a proxy IP address on the client switch ports. 

When the client requests services from the switch’s virtual server, the client sends its own IP 
address for use as a return address. If a proxy IP address is configured for the client port on the 
switch, the switch replaces the client’s source IP address with the switch’s own proxy IP 
address before sending the request to the real server. This creates the illusion that the switch 
originated the request. 

The real server uses the switch’s proxy IP address as the destination address for any response. 
SLB traffic is forced to return through the proper switch, regardless of alternate paths. Once 
the switch receives the proxied data, it puts the original client IP address into the destination 
address and sends the packet to the client. This process is transparent to the client. 


NOTE — Because requests appear to come from the switch proxy IP address rather than the cli¬ 
ent source IP address, the network administrator should be aware of this behavior during 
debugging and statistics collection. 


The proxy IP address can also be used for direct access to the real servers (see “Direct Server 
Interaction” on page 92). 
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The following procedure can be used for configuring proxy IP addresses: 

1. Disable server processing on affected switch ports. 

When implementing proxies, switch ports can be reconfigured to disable server processing. 
Referring to the Table 6-2 on page 76, the following revised port conditions are used: 


Table 6-4 Proxy Example: Port Usage 


Port 

Host 

L4 Processing 

1 

Server A 

None 

2 

Server B 

None 

3 

Server C 

None 

4 

Back-end NFS server provides centralized Web content for all three 
real servers. This port does not require Web switching features. 

None 

5 

Client router A connects the switch to the Internet where all client 
requests originate. 

Client 

6 

Client router B also connects the switch to the Internet where all client 
requests originate. 

Client 


The following commands are used to disable server processing on ports 1-3: 


>> 

# /cfg/s 

lb/port 1 

(Select switch port 1) 

>> 

SLB 

port 

1# 

server dis 

(Disable seryer processing on port 1) 

>> 

SLB 

port 

1# 

../port 2 

(Select switch port 2) 

>> 

SLB 

port 

2# 

server dis 

(Disable seryer processing on port 2) 

>> 

SLB 

port 

2# 

. . /port 3 

(Select switch port 3) 

>> 

SLB 

port 

3# 

server dis 

(Disable seryer processing on port 3) 


2. Add proxy IP addresses to the client ports. 

Each client port requires a proxy IP address. Each proxy IP address must be unique on your 
network. The following commands are used to configure client proxies: 


>> 

>> 

>> 

>> 


# /cfg/slb/port 5 

SLB port 5# pip 200.200.200.68 

SLB port 5# ../port 6 

SLB port 6# pip 200.200.200.69 


(Select network port 5) 

(Set proxy IP address for client port 5) 
(Select network port 6) 

(Set proxy IP address for client port 6) 


The proxies are transparent to the user. 
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3. If the Virtual Matrix Architecture (VMA) feature is enabled, add proxy IP addresses for 
all other switch ports (except port 9). 

VMA is normally enabled on the switch. In addition to enhanced resource management, VMA 
eliminates many of the restrictions found in earlier versions of the Web OS. VMA does 
require, that when any switch port is configured with a proxy IP address, all ports must be con¬ 
figured with unique proxy IP addresses. If VMA is disabled, only the client port needs a proxy 
IP address and this step can be skipped. 

The following commands can be used for configuring the additional unique proxy IP 
addresses: 


>> 

SLB 

port 

6# 

/cfg/slb/port 1 

(Select network port 1) 

>> 

SLB 

port 

1# 

pip 200.200.200.70 

(Set proxy IP address for port 1) 

>> 

SLB 

port 

1# 

../port 2 

(Select network port 2) 

>> 

SLB 

port 

2# 

pip 200.200.200.71 

(Set proxy IP address for port) 

>> 

SLB 

port 

2# 

../port 3 

(Select network port 3) 

>> 

SLB 

port 

3# 

pip 200.200.200.72 

(Set proxy IP address for port 3) 

>> 

SLB 

port 

3# 

../port 4 

(Select network port 4) 

>> 

SLB 

port 

4# 

pip 200.200.200.73 

(Set proxy IP address for port 4) 

>> 

SLB 

port 

4# 

../port 7 

(Select network port 7) 

>> 

SLB 

port 

7# 

pip 200.200.200.74 

(Set proxy IP address for port 7) 

>> 

SLB 

port 

7# 

../port 8 

(Select network port 8) 

>> 

SLB 

port 

8# 

pip 200.200.200.75 

(Set proxy IP address for port 8) 


NOTE — Port 9 does not require a proxy IP address under VMA. 


For conceptual information, see “Virtual Matrix Architecture” on page 151 of this manual and 
for information on using the commands, see the Web OS 9.0 Command Reference 
(/cfg/sib/adv/matrix) for more information. 

4. Apply and save your changes. 


NOTE — Remember that you must apply any changes in order for them to take effect, and you 
must save them if you wish them to remain in effect after switch reboot. Also, the 
/info/slb command is useful for checking the state of Server Load Balancing operations. 
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Mapping Ports 

An Alteon Web switch allows you to hide the identity of a port for security by mapping a vir¬ 
tual server port to a different real server port. 

Mapping a Virtual Server Port to a Real Server Port 

In addition to providing direct real server access in some situations (see “Mapping Ports” on 
page 94), mapping is required when administrators choose to execute their real server processes 
on different TCP/UDP ports than the well-known TCP/UDP ports. Otherwise, virtual server 
ports are mapped directly to real server ports by default and require no mapping configuration. 

Port mapping is configured from the Virtual Server Services menu. For example, to map the 
virtual server TCP/UDP port 80 to real server TCP/UDP port 8004, you could enter the follow¬ 
ing: 

» # /cfg/slb/virt 1/service 80 (Select virtual server port 80) 

» Virtual Server 1 http Service# rport 8004 (Map to real port 8004) 


NOTE — Port mapping is supported with Direct Access Mode (DAM) when filtering is enabled, 
a proxy IP address is configured, or URL parsing is enabled on any switch port. For informa¬ 
tion about DAM, refer to “Using Direct Access Mode” on page 93. 


Mapping a Single Virtual Server Port to Multiple Real Server Ports 

To take advantage of multi-CPU or multi-process servers, Web OS can be configured to map a 
single virtual port to multiple real ports. This capability allows the Web site managers, for 
example, to differentiate users of a service by using multiple service ports to process client 
requests. 

An Alteon Web switch supports up to eight real ports per server when multiple rport s are 
enabled. This feature allows the network administrator to configure up to eight remote ports 
for a single service port. This feature is supported in Layer 4 and Layer 7 and in cookie-based 
and SSL persistence switching environments. 

When multiple real ports on each real server are mapped to a virtual port, the Web switch treats 
the real server IP address/port mapping combination as a distinct real server. 


NOTE — For each real server, you can only configure one service with multiple real ports. 
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Consider the following network: 


Web Clients 


Real Servers 



192.168.2.4 

8001 

8002 


Figure 6-6 Basic Virtual Port to Real Port Mapping Configuration 


Domain Name Virtual IP 
Address 

Ports Activated 

Port Mapping 

Real Server IP 
Address 

www.right.com 192.168.2.100 

80 (HTTP) 

8001 (rport 1) 

8002 (rport 2) 

192.168.2.1 (RIP 1) 

192.168.2.2 (RIP 2) 

192.168.2.3 (RIP 3) 

192.168.2.4 (RIP 4) 


In this example, four real servers are used to support a single service (HTTP). Clients access 
this service through a virtual server with IP address 192.168.2.100 on virtual port 80. Since 
each real server uses two ports (8001 and 8002) for HTTP services, the logical real servers are: 

■ 192.168.2.1/8001 

■ 192.168.2.1/8002 

■ 192.168.2.2/8001 

■ 192.168.2.2/8002 

■ 192.168.2.3/8001 

■ 192.168.2.3/8002 

■ 192.168.2.4/8001 

■ 192.168.2.4/8002 
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Load Balancing Metric 

For each service, a real server is selected using the configured load balancing metric (hash, 
leastconns, minmisses, or roundrobin). To ensure even distribution, once an avail¬ 
able server is selected, the switch will use the roundrobin metric to choose a real port to 
receive the incoming connection. 

If the algorithm is leastconns, the switch sends the incoming connections to the logical 
real server (real server IP address/port combination) with the least number of connections. 

The /cfg/slb/virt command defines the real server TCP or UDP port assigned to a ser¬ 
vice. By default, this is the same as the virtual port (service virtual port). If rport is config¬ 
ured to be different from the virtual port defined in /cfg/slb/virt <virtual server 
number>/ service <virtualport>, the switch maps the virtual port to the real port. 


NOTE — To use the single virtual port to multiple rport feature, configure this real server port 
option to be a value of 0. However, note that you cannot configure multiple services with mul¬ 
tiple rport s in the same server if the multiple rport feature is enabled. 


Configuring Multiple Service Ports 

Two commands, addport and remport, under the real server menu allow users to add or 
remove multiple service ports associated with a particular server. (A service port is a TCP or 
UDP port number.) For example: addport 8001 and remport 8001. 

1. Configure the real servers. 


>> # /cfg/slb/real 1/rip 192.168.2.1/ena 
>> # ../real 2/rip 192.168.2.2/ena 
» # ../real 3/rip 192.168.2.3/ena 
>> # ../real 4/rip 192.168.2.4/ena 


2. Add all four servers to a group. 


>> 

# /cfg/slb/group 1 




>> 

Real 

server 

Group 

1# 

add 

1 

>> 

Real 

server 

Group 

1# 

add 

2 

>> 

Real 

server 

Group 

1# 

add 

3 

>> 

Real 

server 

Group 

1# 

add 

4 


3. Configure a virtual IP address. 


>> # /cfg/slb/virt 1/vip 192.168.2.100/ena 
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4. Turn on multiple rport for Port 80. 


» # /cfg/slb/virt 1/service 80/rport 0 


5. Add the ports to which the Web server listens. 


>> 

# 

/cfg/slb/real 1/addport 8001 

(Add port 8001 to real server 1) 

>> 

# 

addport 

8002 


(Add port 8002 to real server 1) 

>> 

# 

../real 

2/addport 

8001 

(Add port 8001 to real server 2) 

>> 

# 

addport 

8002 


(Add port 8002 to real server 2) 

>> 

# 

../real 

3/addport 

8001 

(Add port 8001 to real server 3) 

>> 

# 

addport 

8002 


(Add port 8002 to real server 3) 

>> 

# 

../real 

4/addport 

8001 

(Add port 8001 to real server 4) 

>> 

# 

addport 

8002 


(Add port 8002 to real server 4) 


Health Checking Issues 

If the multi rport option is enabled, each server’s service is added to the service’s health- 
check table. 

If any service running on a real server fails, that server is removed from the real server group, 
and the server will be taken offline. Traffic can only be directed to a particular server in a real 
server group if all of the services configured on that server are up and available. 
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Direct Server Interaction 


Direct access to real servers can be provided in the following ways: 


■ Direct Server Return 

■ Using Direct Access Mode 

■ Assigning Multiple IP Addresses 

■ Using Proxy IP Addresses 

■ Mapping Ports 

■ Monitoring Real Servers 

Direct Server Return 

Some clients may need direct access to the real servers (for example, to monitor a real server 
from a management workstation). The Direct Server Return (DSR) feature allows the server to 
respond directly to the client. This capability is useful for sites where large amounts of data are 
flowing from servers to clients, such as with content providers or portal sites that typically 
have asymmetric traffic patterns. 

DSR and content-intelligent Layer 7 switching cannot be performed at the same time because 
content intelligent switching requires that all frames go back to the switch for connection splic¬ 
ing. 


NOTE — DSR requires that the server be set up to receive frames that have a destination IP 
address that is equal to the virtual server IP address. 


The sequence of steps that are executed in this scenario are shown in Figure 6-7: 



Client 


Internet 



Figure 6-7 Direct Server Return 
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1. A client request is forwarded to the Web switch. 

2. Because only MAC addresses are substituted, the switch forwards the request to the best 
server, based on the configured load-balancing policy. 

3. The server responds directly to the client, bypassing the switch, and using the virtual 
server IP address as the source IP address. 

To set up DSR, use the following commands: 


>> # /cfg/slb/real <real server number>/ submac ena 

» # /cfg/slb/virt <virtual server nwnber>/ service <seryice number> /nonat ena 


Using Direct Access Mode 

When Direct Access Mode (DAM) (/ cfg/slb/direct) is enabled on a switch, any client 
can communicate with any real server’s load-balanced service. Also, with DAM enabled, any 
number of virtual services can be configured to load balance a real service. 

Traffic sent directly to real server IP addresses is excluded from load-balancing decisions. The 
same clients may also communicate to the virtual server IP address for load-balanced requests. 


NOTE — When DAM is enabled on a switch, port mapping and default gateway load balancing 
is supported only when filtering is enabled, a proxy IP address is configured, or URL parsing is 
enabled on any switch port. 


Assigning Multiple IP Addresses 

One way to provide both SLB access and direct access to a real server is to assign multiple IP 
addresses to the real server. For example, one IP address could be established exclusively for 
SLB and another could be used for direct access needs. 

Using Proxy IP Addresses 

Proxy IP addresses are used primarily to eliminate SLB topology restrictions in complex net¬ 
works (see “Proxy IP Addresses” on page 85). Proxy IP addresses can also provide direct 
access to real servers. 

If the switch port to the client is configured with a proxy IP address, the client can access each 
real server directly using the real server’s IP address. The switch port must be connected to the 
real server and client processing must be disabled (see the server and client options 
under the /cfg/slb/port command in your Web OS 9.0 Command Reference). 

SLB is still accessed using the virtual server IP address. 
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Mapping Ports 

When SLB is used without proxy IP addresses and without DAM, the Web switch must pro¬ 
cess the server-to-client responses. If a client were to access the real server IP address and port 
directly, bypassing client processing, the server-to-client response could be mishandled by 
SLB processing as it returns through the Web switch, with the real server IP address getting 
remapped back to the virtual server IP address on the Web switch. 

First, two port processes must be executed on the real server. One real server port will handle 
the direct traffic, and the other will handle SLB traffic. Then, the virtual server port on the Web 
switch must be mapped to the proper real server port. 

In Figure 6-8, clients can access SLB services through well-known TCP port 80 at the virtual 
server’s IP address. The Web switch behaving like a virtual server is mapped to TCP port 8000 
on the real server. For direct access that bypasses the virtual server and SLB, clients can spec¬ 
ify well-known TCP port 80 as the real server’s IP address. 


Direct Access 

via Real Server IP & Port 



Client 

Network 


Virtual Server on the 
Alteon Web Switch 


Real 

Server 


Layer 4 Mapped Access 
via Virtual Server IP & Port 

Figure 6-8 Mapped and Non-Mapped Server Access 


NOTE — Port mapping is supported with DAM when filtering is enabled, a proxy IP address is 
configured, or URL parsing is enabled on any switch port. 


For more information on how to map a virtual server port to a real server port, see “Mapping 
Ports” on page 88. 
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Monitoring Real Servers 

Typically, the management network is used by network administrators to monitor real servers 
and services. By configuring the mnet and mmask options of the SLB Configuration Menu 
(/cfg/sib/adv), you can access the real services being load balanced. 


NOTE — Clients on the management network do not have access to SLB services and cannot 
access the virtual services being load balanced. 


The mnet and mmask options are described below: 

■ mnet: If defined, management traffic with this source IP address is allowed direct (non- 
SLB) access to the real servers. Only specify an IP address in dotted decimal notation. A 
range of IP addresses is produced when used with the mmask option. 

■ mmask: This IP address mask is used with mnet to select management traffic that is 
allowed direct real server access only. 
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Delayed Binding 

The delayed binding feature on the switch prevents SYN Denial-of-Service (DoS) attacks on 
the server. DoS occurs when the server or switch is denied servicing the client because it is sat¬ 
urated with invalid traffic. 

Typically, a three-way handshake occurs before a client connects to a server. The client sends 
out a synchronization (SYN) request to the server. The server allocates an area to process the 
client requests, and acknowledges the client by sending a SYN ACK. The client then acknowl¬ 
edges the SYN ACK by sending an acknowledgement (ACK) back to the server, thus complet¬ 
ing the three-way handshake. 

Figure 6-9 on page 96 illustrates a classic type of SYN DoS attack. If the client does not 
acknowledge the server’s SYN ACK with a data request (REQ) and, instead, sends another 
SYN request, the server gets saturated with SYN requests. As a result, all of the servers 
resources are consumed and it can no longer service legitimate client requests. 


Normal Request 


Client 


Mr 


• Client sends a SYN request- 


► Server 


-Server reserves session and sends SYN ACK 


■ Client sends an ACK or DATA REQ- 


'Server responds with DATA 


DoS SYN Attack 


Client 


Mr 


■ Client sends a SYN request- 


3 


► Server 


Server reserves session and sends SYN ACK- 
■Client ignores SYN ACK and continues to send new SYN requests — 


Server continues reserving sessions. 
Server is eventually saturated and 
cannot process legitimate requests. 


3 


Figure 6-9 DoS SYN Attacks Without Delayed Binding 


Using an Alteon Web switch with delayed binding, as illustrated in Figure 6-10 on page 97, the 
Web switch intercepts the client SYN request before it reaches the server. The Web switch 
responds to the client with a SYN ACK that contains embedded client information. The Web 
switch does not allocate a session until a valid SYN ACK is received from the client or the 
three-way handshake is complete. 
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Normal Request with Delayed Binding 
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DoS SYN Attack with Delayed Binding 


Client 
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Figure 6-10 Repelling DoS SYN Attacks With Delayed Binding 


Once the Web switch receives a valid ACK or DATA REQ from the client, the Web switch 
sends a SYN request to the server on behalf of the client, waits for the server to respond with a 
SYN ACK, and then forwards the clients DATA REQ to the server. Basically, the Web switch 
delays binding the client session to the server until the proper handshakes are complete. 

Thus, with delayed binding, two independent TCP connections span a Web session: one from 
the client to the Web switch and the second from the Web switch to the selected server. The 
switch temporarily terminates each TCP connection until content has been received, thus pre¬ 
venting the server from being inundated with SYN requests. 


NOTE — Delayed binding is automatically enabled when content intelligent switching features 
are used. However, if you are not parsing content, you must explicitly enable delayed binding 
if desired. 
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Configuring Delayed Binding 

To configure your switch for delayed binding, use the following command: 


>> # /cfg/slb/virt <virtual server number >/service <service fype>/dbind 


NOTE — Enable delayed binding without configuring any HTTP SLB processing or persistent 
binding types. 


To configure delayed binding for Web cache redirection, see “Delayed Binding for Web Cache 
Redirection” on page 146. 

Troubleshooting SYN Attacks 

The probability of a SYN attack is higher if there are half-open connections on the Web switch. 
The half-open connections parameter shows an incomplete three-way handshake 
between the server and the client. You can view the total number of half-open connections 
from the URL SLB statistics menu: 


>>/stat/slb/url/maint 

URL SLB/WCR maintenance stats: 

No available sequence buffer: 


0 


No available frame buffer: 


0 


Clients reset by switch on client 

side: 

0 


Clients reset by switch on server 

side: 

0 


Connection Splicing to support HTTP/1.1: 

0 


Half open connections: 


0 


Switch retries: 


0 


Random early drops: 


0 


Frame buffer overflow: 


0 


Bytes used for frame buffers: 


0 


Maximum bytes used for frame buffers: 

1773 


Current sequence buffer entries: 

0 

Highest: 

101 


Enable delayed binding if the number of half-open connections increases. 
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Load Balancing Special Services 


This section discusses load balancing based on special services, such as 

■ IP Server Load Balancing 

■ FTP Server Load Balancing 

■ Real Time Streaming Protocol SLB 

■ Wireless Application Protocol SLB 

■ Intrusion Detection System SLB 

■ WAN Link Load Balancing 

IP Server Load Balancing 

IP server load balancing allows you to configure your Web switch for server load balancing 
based on client’s IP address only. Typically, the client IP address is used with the client port 
number to produce a session identifier. When the Layer 3 option is enabled, the switch uses 
only the client IP address as the session identifier. 

To configure the switch for IP load balancing: 


» # /cfg/slb/virt <virtual server number> 

» Virtual Server 1# layr3 ena 
» Virtual Server 1# service ip 

» Virtual Server 1 IP Service# group <group number > 


IP server load balancing is used if IP traffic is totally encrypted and you do not have access to 
the content. 

FTP Server Load Balancing 

As defined in RFC 959, FTP uses two connections: One for control information and another 
for data. Each connection is unique. Unless the client requests a change, the server is always 
using TCP port 21 (a well-known port) for control information and TCP port 20 as the default 
data port. 

FTP uses TCP for transport. After the initial three-way handshake, a connection is established. 
When the client requests any data information from the server, it will issue a PORT command 
(such as Is, dir, get, put, mget and mput) via the control port. 
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There are two modes of FTP operation, active and passive: 

■ In Active FTP, the FTP server initiates the data connection. 

■ In Passive FTP, the FTP client initiates the data connection. Because the client also ini¬ 
tiates the connection to the control channel, the passive FTP mode does not pose a prob¬ 
lem with firewalls and is the most common mode of operation. 

FTP Network Topology Restrictions 

FTP network topology restrictions are listed below: 

■ FTP uses both a control channel and a data channel; both channels need to be bound to the 
same real server. 

■ The FTP server may initiate FTP data sessions. 

■ Information exchanged on the control channel is used to determine the IP address and port 
for data connections between the FTP server and the FTP client. 

Configuring FTP Server Load Balancing 

1. Make sure that a proxy IP address is enabled on the client port(s) or DAM is enabled. 

2. Make sure the virtual port for FTP is set up for the virtual server. 


>> # /cfg/slb/virt <virtual server number> 
» Virtual Server 1# service ftp 


3. Enable FTP parsing. 


>> Virtual Server 1 ftp Service# ftpp ena 


4. To make your configuration changes active, enter apply at any prompt in the CLI. 


>> Virtual Server 1 ftp Service # apply 


NOTE — You must apply any changes in order for them to take effect, and you must save 
them if you wish them to remain in effect after switch reboot. 
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Real Time Streaming Protocol SLB 

Real Time Streaming Protocol (RTSP) is an application-level protocol for control over the 
delivery of data with real-time properties as documented in RFC 2326. 

RTSP is used as a “network remote control” for multimedia servers. Typically, a multimedia 
presentation consists of several streams of data (for example, video stream, audio stream, and 
text) that must be presented in a synchronized fashion. A multimedia client like Real Player or 
Quick Time Player downloads these multiple streams of data from the multimedia servers and 
presents them on the player screen. 

RTSP is used to control the flow of these multimedia streams. Each presentation uses one 
RTSP control connection and several other connections to carry the audio/video/text 
multimedia streams. In this document, the term RTSP server refers to any multimedia server 
that implements the RTSP protocol for multimedia presentation. 

How RTSP Server Load Balancing Works 

The objective of RTSP server load balancing is to intelligently switch an RTSP request, and the 
other media streams associated with a presentation, to a suitable RTSP server based on the 
configured load-balancing metric. Currently, Web OS 9.0 supports one Layer 7 metric (URL 
hashing) and all Layer 4 load-balancing metrics. 

RTSP load balancing with the URL hash metric can be used to load balance cache servers 
that cache multimedia presentations. Since multimedia presentations consume a large amount 
of Internet bandwidth, and their correct presentation depends upon the real time delivery of the 
data over the Internet, several caching servers cache the multimedia data. As a result, the data 
is available quickly from the cache, when required. The Layer 7 metric of URL hashing directs 
all requests with the same URL to the same cache server, ensuring that no data is duplicated 
across the cache servers. 

Typically, an RTSP client establishes a control connection to an RTSP server over TCP port 
554 and issues RTSP commands to it. On receiving the first command, the switch chooses an 
RTSP server, using the configured Layer 4 metric. The switch then routes the request by splic¬ 
ing a connection to the server. 


NOTE — This feature is not applicable if the streaming media (multimedia) servers use HTTP 
protocol to tunnel RTSP traffic. To ensure RTSP server load balancing works, make sure the 
streaming media server is configured for RTSP protocol. 
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In a typical scenario, the RTSP client issues several sequences of commands to establish con¬ 
nections for each component stream of a presentation. There are several variations to this pro¬ 
cedure, depending upon the RTSP client and the server involved. For example, there are two 
prominent RTSP server and client implementations: Real Server marketed by Real Networks 
Corporation, and Quicktime Streaming Server marketed by the Apple Inc. The RTSP stream 
setup sequence is different for these two servers, and the switch handles each differently. Some 
of these differences are described below. 

■ Real Server 

Real Server is the dominant product in the multimedia field. The real media files that the 
Real Server plays have the extension “.rm”, “.ram” or “.smil”. 

Real Server supports both UDP and TCP transport protocols for the RTSP streams. The 
actual transport is negotiated during the initialization of the connection. If TCP transport is 
selected, then all streams of data will flow in the TCP control connection itself. If UDP 
transport is chosen, the client and server negotiate a client UDP port ranging from 6970 to 
7000 to set up each stream connection. 

■ QuickTime Streaming Server 

The second dominant player in the multimedia presentation is Apple Inc.’s QuickTime 
Streaming Server that typically runs on the Apple platforms. QuickTime files that can be 
played over the Internet using RTSP are specially formatted and are called “hinted Quick¬ 
Time files.” Normal QuickTime files cannot be used for streaming. The QuickTime files 
have the extension “.mov”. 

QuickTime uses UDP protocol exclusively for transport and TCP for control connection. 
Each stream of a QuickTime presentation sends Real Time Protocol (RTP), and Real Time 
Control Protocol (RTCP) data using two UDP connections. Typically, a QuickTime pre¬ 
sentation has two streams and therefore uses four UDP connections and one TCP control 
connection. QuickTime clients use a UDP port ranging from 6970 to 6999 for setting up 
stream connections. 
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RTSP Implementation 

RTSP implementation in WEB OS 9.0 supports the following: 

■ Alteon AD3, Alteon AD4, Alteon 180e, and Alteon 184 platforms 

■ Private addressing on the server side 

■ All Layer 4 metrics and one Layer 7 URL-hashing metric for load balancing. 

■ All the stream connections and the control connections are switched to the same cache 
server to facilitate caching of entire presentations. 

■ RTSP-compliant applications (excludes Windows Media Player because it is not RTSP 
compliant). 

Configuring RTSP Load Balancing 

Before configuring your Web switch for RTSP load balancing, do the following: 

■ Enable Virtual Matrix Architecture (VMA) 

■ Enable Direct Access Mode (DAM) 

■ Disable port-based Bandwidth Management 

■ Disable Web Cache Redirection 

■ Disable proxy IP addressing 

1. To configure a virtual server for Layer 4 load balancing of RTSP, select rtsp or port 
554 as a service for the virtual server. 


>> # /cfg/slb/virt <virtual server number >/service rtsp 


2. To configure a virtual server for Layer 7 URL hashing of RTSP, select rtsp as a virtual 
service and enable rtspslb. 


» # /cfg/slb/virt 1/service rtsp/rtspslb ena 


This command enables URL hashing using the entire URL; however, any extension of the type 
(.XXX) occurring at the end of the URL is omitted from hash computation. 
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Wireless Application Protocol SLB 

Wireless Application Protocol (WAP) is an open, global specification for a suite of protocols 
designed to allow wireless devices to communicate and interact with other devices. It 
empowers mobile users with wireless devices to easily access and interact with information 
and services instantly by allowing non-voice data, such as text and images, to pass between 
these devices and the Internet. Wireless devices include cellular phones, pagers. Personal 
Digital Assistants (PDAs), and other hand-held devices. 

WAP supports most wireless networks and is supported by all operating systems—with the 
goal of inter-operability. A WAP Gateway translates Wireless Markup Language (WML)— 
which is a WAP version of HTML—into HTML/HTTP so that requests for information can be 
serviced by traditional Web servers. 

To load balance WAP traffic among available parallel servers, the switch must provide persis¬ 
tency so that the clients can always go to the same WAP gateway to perform WAP operation. 

In the earlier releases of Web OS, the switch was not able to determine which WAP gateway 
the request should go to if the client’s IP address changes. (The client’s IP address as well as 
the remote access server, changes when the user moves from one area to another.) 

In Web OS 9.0, the Web switch is able to decide to which real gateway the request should go. 
WAP SLB is based on RADIUS static session entry or RADIUS snooping. 

The following topics are discussed in this section: 

■ Using RADIUS Static Session Entries 

■ Using RADIUS Snooping 

■ Preconfiguring WAP Server Load Balancing 

■ Enabling Wireless Application Protocol SLB 

■ Configuring RADIUS Snooping 

Using RADIUS Static Session Entries 

RADIUS is a client/server protocol and software that enables remote access servers to commu¬ 
nicate with a central server to authenticate dial-in users and authorize their access to the 
requested network or service. RADIUS allows a company to maintain user profiles in a central 
database that all remote servers can share. It provides better security, allowing a company to 
set up a policy that can be applied at a single administered network point. RADIUS is an indus¬ 
try standard used by network product companies and is a proposed IETF standard. 
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The RADIUS server uses a static session entry to determine which real WAP gateway should 
receive the user’s sessions. Typically, each WAP gateway is integrated with a RADIUS server 
on the same host, and a RADIUS request packet is allowed to go to any of the RADIUS 
servers. Upon receiving a request from a client, the RADIUS server instructs the switch to 
create a static session entry in the switch via Transparent Proxy Control Protocol (TPCP). 
TPCP is Alteon’s proprietary protocol that is used to establish communication between the 
RADIUS servers and the Alteon Web switch. It is UDP-based and uses port 3121. 

Using this feature, a static session entry is added or removed by the external devices, such as 
the RADIUS servers. A regular session entry is usually added or removed by the switch itself. 
A static session entry, like a regular session entry, contains such information as the client IP 
address, the client port number, real port number, virtual (destination) IP address, virtual (des¬ 
tination) port number, and so forth. 

A static session entry added via TPCP to the switch does not age out. The entry will only be 
deleted by another TPCP Delete Session request. If the user adds session entries using 
the traditional server load balancing methods, the entries will continue to age out. 

Since TPCP is UDP-based, the Add/Delete Session requests may get lost during trans¬ 
mission. The WAP gateway issues another Add Session request on detecting that it has lost 
a request. The WAP gateway detects this situation when it receives WAP traffic that does not 
belong to that WAP gateway. If a Delete Session request is lost, it will be overwritten by 
another Add Session request. 


How Wireless Application Protocol SLB Works using Static Session Entries 

1. On dialing, the user is first authenticated by the Remote Access Server (RAS). 

2. The RAS sends a RADIUS authentication request to one of the RADIUS servers, which 
can be integrated with a WAP gateway. 

3. If the user is accepted, the RADIUS server determines which WAP gateway is right for 
this user and informs the switch of the decision via TPCP. 

4. The switch receives an Add Session request from the RADIUS server and adds a ses¬ 
sion entry to its session table to bind a WAP gateway with that user. 

5. A response (RADIUS Accept) packet is sent back to the RAS by the RADIUS server. 

6. The RAS receives a RADIUS Accept packet and allows the WAP traffic for that user. 

7. If the user disconnects, the RAS detects it and sends a RADIUS Accounting Stop 
message to the RADIUS server. 

8. The RADIUS server sends a Delete session message and removes the session entry 
for that user. 
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Using RADIUS Snooping 

Radius snooping allows the Alteon Web switch to examine RADIUS accounting packets for 
client information. This information is needed to add to or delete static session entries to the 
session table of the switch so that it can perform the required persistency for load balancing. A 
static session entry does not age out. Such an entry, added using RADIUS Snooping, will only 
be deleted using RADIUS Snooping. The switch load balances both the RADIUS and WAP 
gateway traffic using the same virtual server IP address. 

How WAP SLB Works Using RADIUS Snooping 

Before the RAS allows the WAP traffic for a user to pass in and out of the gateway, it sends a 
RADIUS Accounting Start message to one of the RADIUS Servers. The switch then 
snoops on the packet to extract the information it needs. It needs to know the type of the 
RADIUS Accounting message, the client IP address, the caller ID, and the user’s name. If it 
finds this information, the switch adds a session entry to its session table. If any of this infor¬ 
mation is missing, the switch will not take any action to handle the session entry. 

When the client ends the WAP connection, RAS sends RADIUS Accounting Stop 
packet. If the switch finds the needed information in a RADIUS Accounting Stop packet, 
it removes the corresponding session entry from its table. The following steps occur for 
RADIUS snooping: 

1. The user is authenticated on dialing. 

2. The RAS establishes a session with the client and sends a RADIUS Accounting Start mes¬ 
sage with the client IP address to the RADIUS server. 

3. The switch snoops on the RADIUS accounting packet and adds a session entry if it finds 
enough information in the packet. 

4. The switch load balances the WAP traffic to a specific WAP gateway. 

5. When the client terminates the session, the RAS sends an Accounting Stop message to the 
RADIUS server, and the session entry is deleted from the switch. 
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Preconfiguring WAP Server Load Balancing 

■ Configure WAP server load balancing on Alteon AD4 and Alteon 184 platforms only 

■ Enable Virtual Matrix Architecture (VMA) 

>> # /cfg/slb/adv/matrix ena 

■ Disable DAM (Direct Access Mode) 

>> # /cfg/slb/adv/direct dis 

■ Disable pbind and enable udp under the WAP services (ports 9200 to 9203) menu. 

>> # /cfg/slb/virt <number>/ service <name\number> /pbind dis 
>> # /cfg/slb/virt <number>/ service <name\nwnber> /udp ena 

■ Configure for RADIUS service 1813 and 1645. 

Enabling Wireless Application Protocol SLB 

1. Enable the external notification from WAP gateway to add and delete session request. 

» # cfg/slb/adv/tpcp ena 

2. Enable TPCP for adding and deleting WAP sessions. 

» # cfg/slb/wap/tpcp ena 


Configuring RADIUS Snooping 

Consider the following items before configuring RADIUS snooping: 

■ The same virtual server IP address must be used when load balancing both the RADIUS 
accounting traffic and WAP traffic. 

■ All the RADIUS servers must use the same UDP port for RADIUS accounting services. 

■ Before a session entry is recorded on the switch, WAP packets for a user can go to any of 
the real WAP gateways. 

■ If a session entry for a client cannot be added because of resource constraints, the subse¬ 
quent WAP packets for that client will not be load balanced correctly; and the client will 
need to drop the connection and then reconnect to his wireless service. 
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■ The persistence of a session cannot be maintained if the number of healthy real WAP gate¬ 
ways changes during the session. For example, if a new WAP server comes into service or 
some of the existing WAP servers are down, the number of healthy WAP gateway changes 
and, in this case, the persistence for a user cannot be maintained. 

■ Persistence cannot be maintained if the user moves from one ISP to another, or if the base 
of the user’s session changes (that is, from CALLING_STATION_ID to USER_NAME, or 
vice versa). For example, if a user moves out of a roaming area, it is possible that his/her 
CALLING_STATION_ID is not available in the RADIUS Accounting packets. In such a 
case, the switch uses USER_NAME to choose a WAP server instead of 
CALLING_STATION_ID. Thus, persistence cannot be maintained. 

Configure the following filter on the switch to examine a RADIUS accounting packet: 

1. Set the basic filter parameters. 


>> # /cfg/slb/filt 1 

(Select the filter) 

» # dip 10.10.10.100 

(Set the destination IP address) 

» # dmask 255.255.255.255 

( Set the destination IP mask) 

>> # proto udp 

(Set the protocol to UDP) 

>> # dport 1813 

(Set the destination port) 

>> # action redir 

(Set the action to redirect) 

>> # group 1 

(Set the group for redirection) 

>> # rport 1813 

(Set seri’er port for redirection) 

Turn on proxy and RADIUS snooping. 

>> # adv 

(Select the advance filter menu) 

>> # proxy ena 

(Enable proxy) 

>> # rdsnp ena 

(Enable RADIUS snooping) 


NOTE — Web OS supports Virtual Router Redundancy Protocol (VRRP) and stateful failover, 

using both static session entries and RADIUS snooping. 

However, active-active configuration 

with Stateful Failover is not supported. 
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Intrusion Detection System SLB 

Intrusion Detection System (IDS) is a type of security management system for computers and 
networks. An Intrusion Detection System gathers and analyzes information from various areas 
within a computer or a network to identify possible security breaches, which include both 
intrusions (attacks from outside the organization) and misuse (attacks from within the organi¬ 
zation). 

Intrusion detection functions include: 

■ Monitoring and analyzing both user and system activities 

■ Analyzing system configurations and vulnerabilities 

■ Assessing system and file integrity 

■ Recognizing patterns typical of attacks 

■ Analyzing abnormal activity patterns 

■ Tracking user policy violations 

Intrusion detection devices inspect every packet before it enters a network, looking for any 
signs of an attack. The attacks are recorded and logged in an attempt to guard against future 
attacks and to record the information about the intruders. 

IDS Server Load Balancing helps scale intrusion detection systems since it is not possible for 
an individual server to scale information being processed at gigabit speeds. 

How Intrusion Detection Server Load Balancing Works 

In Web OS 9.0, the switch forwards the IP packets to an Intrusion Detection server at the end 
of the filtering process or at the end of client processing (when filtering is not enabled). The 
user must enable IDS SLB on the port and allocate a real server group for IDS Server Load 
Balancing. The IDS SLB-enabled switch copies all incoming packets to this group of intrusion 
detection servers. For each session entry created on the switch, an IDS server is selected based 
on the IDS server load-balancing metric. 

The IDS server receives copies of all the processed frames that are forwarded to the destination 
devices. Session entries are maintained so that all the frames of a given session are forwarded 
to the same IDS server. 

Each IDS server must be connected directly to a different switch port or VLAN because no 
field in the packet header can be substituted. Substituting a field would corrupt the packet that 
must also be forwarded to its real destination. 
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Load Balancing Metrics for IDS 

The following metrics are supported in IDS load balancing: 

■ minmisses 

■ roundrobin 

When used with IDS SLB, this metric requies that delayed binding be disabled. 

■ hash 

To select a real server, Web OS allows you to implement the hash metric in two ways: 

□ Client processing on port 

If the port is configured for client processing only, then the switch hashes on the 
source IP address. 

□ Filter processing on the port 

If a filter is configured on the port, then the switch allows you to hash with source IP 
address, destination IP address, or both. 


NOTE — The leastconns, bandwidth, and response metrics are not applicable to IDS 
SLB. 
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Configuring IDS 

Before you start configuring your switch to support IDS, enable port mirroring on the IDS port 
to capture the Layer 2 packets. For more information on port mirroring, see the Web OS Com¬ 
mand Reference. 


NOTE — IDS SLB is supported only when RTSP SLB or WAP RADIUS Snooping are disabled 
on the Web switch. 


To configure your switch for IDS, do the following: 

1. Create a group and add IDS servers to the group. 

Each IDS server must be connected directly to a different switch port or VLAN. If the IDS 
group will be configured for link health check, match the IDS server number to the physical 
port number (1 to 9) to which it is connected. For ICMP health check, the IDS server number 
can be between 1 and 31. 


>> # /cfg/slb/group <group number> 

>>Real Server Group # add 1 
>>Real Server Group # add 2 

(Define a group) 

(Add IDS ser\’er 1) 

(Add IDS sewer 2) 

Define the IDS server load balancing group. 

» # /cfg/slb/adv/idslb <group number> 

(Select the group with the IDS servers) 

Enable the IDS ports. 

>> # /cfg/slb/port 5 

>> SLB port 5# idslb ena 
>> SLB port 5# ../port 6 
» SLB port 6# idslb ena 

(Select IDS port) 

(Enable IDS on port 5) 

(Select IDS port 6) 

(Enable IDS on port 6) 


4. Define the group health check. 

If you implemented IDS without an IP address, link health check is specifically developed for 
IDS load balancing. Use ICMP health check if your IDS servers are configured with an IP 
address. 


>> # /cfg/slb/group <group number >/health link 
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WAN Link Load Balancing 

Wide Area Networking (WAN) is a telecommunications network system spread across a broad 
geographic area. A WAN may be privately owned or rented, but the term usually means the 
inclusion of public (shared user) networks, such as the telephone system. WANs can also be con¬ 
nected through leased lines and satellites. WANs are typically composed of powerful routers and 
switches that link business enterprises, universities, remote offices, and so on, around the world. 

To handle the high volume of data on the Internet, some corporations are using more than one 
Internet Service provider (ISP) as a way to increase reliability of Internet connections. Such 
enterprises with more than one ISP are referred to as being multihomed. In addition to reliabil¬ 
ity, a multi-homed network architecture enables enterprises to distribute load among multiple 
connections and to provide more optimal routing. 

The WAN link load-balancing feature introduces additional resilience for networks in multi¬ 
homed environment. When users want to control which WAN link the traffic traverses, WAN 
link load balancing can be used to steer requests initiated within the user’s network and his/her 
responses over the appropriate link at that moment in time. 

How WAN Link Load Balancing Works 

Earlier versions of Web OS supported two types of link load balancing: default gateway and 
redirection. In both these methods, the traffic directed to a gateway did not traverse back from 
the same gateway. Also, users typically configured static routes manually or let Border Gate¬ 
way Protocol (BGP) decide which link was best. These methods, unfortunately, did not take 
into account the amount of load on each link, the speed of each link, and the health of devices 
on the other end of the links. 

With Web OS 9.0, the switch uses redirection filters to redirect traffic initiated from within the 
user’s network to a group of devices that exist at the other end of the WAN link (routers, for 
example). These filters determine which link is the best at the time the request is generated. To 
ensure that the responses traverse the same link, the source IP address of the request is trans¬ 
lated to one of the addresses that the selected ISP owns. 

The design of WAN link load balancing is identical to standard redirection, except that it 
substitutes the source IP address of each frame with the proxy IP address of the port to which 
the WAN link is connected. 
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Configuring WAN Link Load Balancing 

Before you start configuring for WAN Link load balancing, make sure of the following: 

■ Disable NAT Web Cache Redirection. WAN Link load balancing and NAT Web Cache 
Redirection cannot be configured on the same switch. 

■ Configure the load balancing metric for response time (response) only. 

■ Do not configure your ports into trunk groups. 

■ Do not configure WAN link load balancing with two or more WAN links connected 
through the same switch port. This feature uses the proxy IP address of the destination port 
when translating the source IP address of the requests. 

To configure the switch for WAN link load balancing: 

1. Define real server 1 with proxy disabled. 


>> 

# /cfg/slb/real 1 

(Select the real server menu) 

>> 

Real server 1# ena 

(Enable real server 1) 

>> 

Real server 1# rip <IP address> 

(Set the real server IP address) 

>> 

Real server 1# proxy dis 

(Disable proxy) 


2. Add real server 1 to group 1 with metric response. 


» # /cfg/slb/group 1 

» Real server group 1# add 1 
» Real server group 1# metric response 


3. Define WAN link load balancing redirect filter. 


>> # /cfg/slb/filt 1 

>> Filter 1# ena 
» Filter 1# action redir 

» Filter 1# group 1 


4. Enable WAN link load balancing for redirect filter. 


>> # /cfg/slb/filt 1/adv/linklb ena 


5. Enable WAN link load balancing proxy for redirect filter. 


» # /cfg/slb/filt 1/adv/proxy ena 
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Chapter 7 

Filtering 


This chapter provides a conceptual overview of filters and includes configuration examples 
showing how filters can be used for network security and Network Address Translation (NAT). 
The following topics are discussed in this chapter: 

■ “Overview” on page 116. This section describes the benefits and filtering criteria to allow 
for extensive filtering at the IP and TCP/UDP levels. 

□ “Filtering Benefits” on page 116 

□ “Filtering Criteria” on page 116 

□ “Stacking Filters” on page 118 

□ “Overlapping Filters” on page 118 

□ “The Default Filter” on page 119 

□ “Optimizing Filter Performance” on page 119 

□ “Filter Logs” on page 120 

□ “IP Address Ranges” on page 121 

■ “Security Example” on page 122. This section provides an example of configuring filters 
for providing the best security. It is generally recommended that you configure filters to 
deny all traffic except for those services that you specifically wish to allow. 

■ “Network Address Translation Examples” on page 128. This section provides two exam¬ 
ples: Internal client access to the Internet, and external client access to the server. 

■ “Matching TCP Flags” on page 133. This section describes the ACK filter criteria which 
provides greater filtering flexibility. 

■ “Matching ICMP Message Types” on page 137. This section lists ICMP message types 
that can be filtered. 


Alteon ((^Systems 115 

050159A, May 2001 



Web OS 9.0 Application Guide 


Overview 


Alteon Web switches are used to deliver content efficiently and secure your servers from unau¬ 
thorized intrusion, probing, and Denial-of-Service (DoS) attacks. Web OS includes extensive 
filtering capabilities at the IP and TCP/UDP levels. 

Filtering Benefits 

Layer 3 (IP) and Layer 4 (application) filtering give the network administrator a powerful tool 
with the following benefits: 

■ Increased security for server networks 

Filters can be configured to allow or deny traffic according to various IP address, protocol, 
and Layer 4 port criteria. This gives the administrator control over the types of traffic per¬ 
mitted through the switch. Any filter can be optionally configured to generate system log 
messages for increased security visibility. 

■ Used to map the source or destination IP addresses and ports 

Generic Network Address Translation (NAT) can be used to map the source or destination 
IP addresses and the ports of private network traffic to or from advertised network IP 
addresses and ports. 

Filtering Criteria 

Up to 2048 filters can be configured on Alteon 184 and Alteon AD4 Web switches. Up to 224 
filters are supported on other Alteon Web switches. Each filter can be set to allow, deny, redi¬ 
rect, or translate traffic based on any combination of the following filter options: 

■ sip: source IP address or range (see “IP Address Ranges” on page 121) 

■ dip: destination IP address or range (dip and dmask) 

■ proto: protocol number or name as shown in Table 7-1 

Table 7-1 Well-Known Protocol Types 


Number 

Protocol Name 

1 

icmp 

2 

igmp 

6 

tcp 

17 

udp 

89 

ospf 

112 

vrrp 
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■ sport: TCP/UDP application or source port as shown in Table 7-2, or source port range 
(such as 31000-33000) 


Table 7-2 Well-Known Application Ports 


Number TCP/UDP 
Application 

Number TCP/UDP 
Application 

Number 

TCP/UDP 

Application 

20 

ftp-data 

70 

gopher 

161 

snmp 

21 

ftp 

79 

finger 

162 

snmptrap 

22 

ssh 

80 

http 

179 

bgP 

23 

telnet 

109 

pop2 

194 

ire 

25 

smtp 

110 

pop3 

220 

imap3 

37 

time 

111 

sunrpc 

389 

ldap 

42 

name 

119 

nntp 

443 

https 

43 

whois 

123 

ntp 

520 

rip 

53 

domain 

143 

imap 

554 

rtsp 

69 

tftp 

144 

news 

1985 

hsrp 


■ dport: TCP/UDP application or destination port as shown in Table 7-2, or destination port 
range (such as 31000-33000) 

■ invert: reverse the filter logic in order to activate the filter whenever the specified condi¬ 
tions are not met. 

■ Advanced filtering options such as TCP flags (page 133) or ICMP message types (page 137) 
are also available. 

Using these filter criteria, you can create a single filter that blocks external Telnet traffic to 
your main server except from a trusted IP address. Another filter could warn you if FTP access 
is attempted from a specific IP address. Another filter could redirect all incoming e-mail traffic 
to a server where it can be analyzed for spam. The options are nearly endless. 
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Stacking Filters 

Stacking filters are assigned and enabled on a per-port basis. Each filter can be used by itself or 
in combination with any other filter on any given switch port. The filters are numbered 1 
through 2048 on Alteon 184 and Alteon AD4 Web switches, and 1 though 224 on other Alteon 
Web switches. When multiple filters are stacked together on a port, the filter’s number deter¬ 
mines its order of precedence: the filter with the lowest number is checked first. When traffic is 
encountered at the switch port, if the filter matches, its configured action takes place and the 
rest of the filters are ignored. If the filter criteria doesn’t match, the next filter is tried. 

As long as the filters do not overlap, you can improve filter performance by making sure that 
the most heavily utilized filters are applied first. For example, consider a filter system where 
the Internet is divided according to destination IP address: 


Filtering by Destination IP Address Ranges 

0.0.0.0 .....► 255.255.255.255 

| Deny [Allow | Deny | Redirect | 

Filter 2 Filter 4 Filter 3 Filter 1 


Figure 7-1 Assigning Filters According to Range of Coverage 

Assuming that traffic is distributed evenly across the Internet, the largest area would be the 
most utilized and is assigned to Filter 1. The smallest area is assigned to Filter 4. 

Overlapping Filters 

Filters are permitted to overlap, although special care should be taken to ensure the proper 
order of precedence. When overlapping filters are present, the more specific filters (those that 
target fewer addresses or ports) should be applied before the generalized filters. 

Example: 


Filtering by Destination IP Address Ranges 

0.0.0.0.-.► 255.255.255.255 

| Deny | Redirect | 

|Allow | 

Filter 3 Filter 2 Filter 1 


Figure 7-2 Assigning Filters to Overlapping Ranges 

In this example, the Filter 2 must be processed prior to Filter 3. If the Filter 3 was permitted to 
take precedence. Filter 2 could never be triggered. 
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The Default Filter 

Before filtering can be enabled on any given port, a default filter should be configured. This 
filter handles any traffic not covered by any other filter. All the criteria in the default filter must 
be set to the full range possible (any). For example: 


Filtering by Destination IP Address Ranges 

0.0.0.0.► 255.255.255.255 


Deny 

Allow 


Redirect 


Filter 224 Filter 2 Filter 1 

Figure 7-3 Assigning a Default Filter 


In this example, the default filter is defined as Filter 224 in order to give it the lowest order of 
precedence. All matching criteria in Filter 224 are set to the any state. If no other filter acts on 
the traffic. Filter 224 processes it, denying and logging unwanted traffic. 


>> 

# /cfg/slb/filt 224 

(Select the default filter) 

>> 

Filter 

224# 

sip any 

(From any source IP addresses) 

>> 

Filter 

224# 

dip any 

(To any destination IP addresses) 

>> 

Filter 

224# 

proto any 

(For any protocols) 

>> 

Filter 

224# 

action deny 

(Deny matching traffic) 

>> 

Filter 

224# 

ena 

(Enable the default filter) 

>> 

Filter 

224# 

adv 

(Select the advanced menu) 

>> 

Filter 

224 Advanced# log enable 

(Log matching traffic to syslog) 


Default filters are recommended (but not required) when configuring filters for IP traffic con¬ 
trol and redirection. Using default filters can increase session performance but takes some of 
the session binding resources. If you experience an unacceptable number of binding failures, as 
shown in the Server Load Balancing Maintenance Statistics (/stats/slb/maint), you 
may wish to remove some of the default filters. 

Optimizing Filter Performance 

Filter efficiency can be increased by placing filters that are used most often near the beginning 
of the filtering list. 

It is a recommended practice to number filters in small increments (5, 10, 15, 20, etc.) to make 
it easier to insert filters into the list at a later time. However, as the number of filters increases, 
you can improve performance by minimizing the increment between filters. For example, fil¬ 
ters numbered 2, 4, 6, and 8 are more efficient than filters numbered 20, 40, 60, and 80. Peak 
processing efficiency is achieved when filters are numbered sequentially beginning with 1. 
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Filter Logs 

To provide enhanced troubleshooting and session inspection capability, packet source and des¬ 
tination IP addresses are included in filter log messages. Filter log messages are generated 
when a Layer 3/Layer 4 filter is triggered and has logging enabled. The messages are output to 
the console port, system host log (syslog), and the Web-based interface message window. 

Example: A network administrator has noticed a significant number of ICMP frames on one 
portion of the network and wants to determine the specific sources of the ICMP messages. The 
administrator uses the Command Line Interface (CLI) to create and apply the following filter: 


>> # /cfg/slb/filt 15 

>> Filter 15# sip any 
>> Filter 15# dip any 
>> Filter 15# action allow 

>> Filter 15# proto icmp 

>> Filter 15# ena 

>> Filter 15# adv/log enable 

>> Filter 15 Advanced# /cfg/slb/port 
>> SLB port 7# add 15 

>> SLB port 7# filt ena 

>> SLB port 7# apply 

>> SLB port 7# save 


(Select filter 15) 

(From any source IP address) 

(To any destination IP address) 
(Allows matching traffic to pass) 
(For the ICMP protocol) 

(Enable the filter) 

(Log matching traffic to syslog) 

7 (Select a switch port to filter) 

(Add the filter to the switch port) 
(Enable filtering on the switch port) 
(Apply the configuration changes) 
(Save the configuration changes) 


When applied to one or more switch ports, this simple filter rule will produce log messages 
that show when the filter is triggered, and what the IP source and destination addresses were 
for the ICMP frames traversing those ports. 

Example: Filter log message output is shown below, displaying the filter number, port, source 
IP address, and destination IP address: 


sib: filter 15 fired on port 7, 206.118.93.110 -> 20.10.1.10 
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IP Address Ranges 

You can specify a range of IP addresses for filtering both the source and/or destination IP 
address for traffic. When a range of IP addresses is needed, the source IP (sip) address or des¬ 
tination IP (dip) address defines the base IP address in the desired range, and the source mask 
(smask) or destination mask (dmask) is the mask that is applied to produce the range. 

For example, to determine if a client request’s destination IP address should be redirected to 
the cache servers attached to a particular switch, the destination IP address is masked (bit-wise 
AND) with the dmask and then compared to the dip. 

As another example, the switch could be configured with two filters so that each would handle 
traffic filtering for one half of the Internet. To do this, you could define the following parameters: 


Table 7-3 Filtering IP Address Ranges 


Filter 

Internet Address Range 

dip 

dmask 

1 

0.0.0.0 - 127.255.255.255 

o.o.o.o 

128.0.0.0 

2 

128.0.0.0-255.255.255.255 

128.0.0.0 

128.0.0.0 


Cache-Enabled versus Cache-Disabled Filters 

To improve efficiency, by default, the Web switch performs filter processing only the first 
frame in each session. Subsequent frames in the session are assumed to match the same criteria 
and are automatically treated in the same fashion as the initial frame. These filters create a ses¬ 
sion entry in the Web switch and are known as cache-enabled. 

Some types of filtering (TCP flag and ICMP message type filtering) require each frame in the 
session to be filtered separately. These filters are known as cache-disabled. 

All filters are cache-enabled by default. To change the status of a filter, use the following com¬ 
mands: 


» # /cfg/slb/f ilt <filter nwnber> / adv (Select the advanced filter menu) 

» Filter 1 Advanced # cache ena|dis (Enable or disable filter caching) 


NOTE — Cache-enabled filters should not be applied to the same ports as cache-disabled filters. 
Otherwise, the cache-disabled filters could potentially be bypassed for frames matching the 
cache-enabled criteria. 
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Security Example 


Consider the following sample network: 



Alteon Web Switch 


Internet 


Client Switch 


Router 


Local Clients 


Web Server Mail Server DNS 
205.177.15.2 205.177.15.3 205.177.15.4 

Figure 7-4 Security Topology Example 

In this example, the network is made of local clients on a collector switch, a Web server, a mail 
server, a domain name server, and a connection to the Internet. All the local devices are on the 
same subnet. 

For best security, it is generally recommended that you configure filters to deny all traffic 
except for those services that you specifically wish to allow. In this example, the administrator 
wishes to install basic security filters to allow only the following traffic: 

■ External HTTP access to the local Web server 

■ External SMTP (mail) access to the local mail server 

■ Local clients browsing the World Wide Web 

■ Local clients using Telnet to access sites outside the intranet 

■ DNS traffic 

All other traffic is denied and logged by the default filter. 


NOTE — Since IP address and port information can be manipulated by external sources, filter¬ 
ing does not replace the necessity for a well-constructed network firewall. 
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Example Configuration for the Security Solution 

Before you begin configuring, you must be connected to the switch CLI as the administrator. 

In this example, all filters are applied only to the switch port that connects to the Internet. If 
intranet restrictions are required, filters can be placed on switch ports connecting to local 
devices. 

Also, filtering is not limited to the few protocols and TCP or UDP applications shown in this 
example. See Table 7-1 on page 116 and Table 7-2 on page 117 for a list of other well-known 
protocols and applications. 

1. Assign an IP address to each of the network devices. 

For this example, the network devices have the following IP addresses on the same IP subnet: 

Table 7-4 Web Cache Example: Real Server IP Addresses 


Network Device 

IP address 

Local Subnet 

205.177.15.0-205.177.15.255 

Web Server 

205.177.15.2 

Mail Server 

205.177.15.3 

Domain Name Server 

205.177.15.4 


2. Create a default filter that will deny and log unwanted traffic. 

The default filter is defined as Filter 224 in order to give it the lowest order of precedence: 


>> 

# /cfg/slb/filt 224 

(Select the default filter) 

>> 

Filter 

224# 

sip any 

(From any source IP addresses) 

>> 

Filter 

224# 

dip any 

(To any destination IP addresses) 

» 

Filter 

224# 

proto any 

(For any protocols) 

>> 

Filter 

224# 

action deny 

(Deny matching traffic) 

>> 

Filter 

224# 

ena 

(Enable the default filter) 

>> 

Filter 

224# 

adv/log enable 

(Log matching traffic to syslog) 


NOTE — Because the proto parameter is not top or udp, the source port (sport) and desti¬ 
nation port (dport) values are ignored and may be excluded from the filter configuration. 
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3. Create a filter that will allow external HTTP requests to reach the Web server. 

The filter must recognize and allow TCP traffic with the Web server’s destination IP address 
and HTTP destination port: 


>> 

Filter 

224# . ./filt 1 

(Select the menu for filter 1) 

>> 

Filter 

1# 

sip any 

(From any source IP address) 

>> 

Filter 

1# 

dip 205.177.15.2 

(To Web server dest. IP address) 

>> 

Filter 

1# 

dmask 255.255.255.255 

(Set mask for exact dest. address) 

>> 

Filter 

1# 

proto tcp 

(For TCP protocol traffic) 

>> 

Filter 

1# 

sport any 

(From any source port) 

>> 

Filter 

1# 

dport http 

(To an HTTP destination port) 

>> 

Filter 

1# 

action allow 

(Allow matching traffic to pass) 

>> 

Filter 

1# 

ena 

(Enable the filter) 


4. Create a pair of filters to allow incoming and outgoing mail to and from the mail server. 

Filter 2 allows incoming mail to reach the mail server, and Filter 3 allows outgoing mail to 
reach the Internet: 


» 

Filter 

1# 

../filt 2 

(Select the menu for filter 2) 

» 

Filter 

2# 

sip any 

(From any source IP address) 

» 

Filter 

2# 

dip 205.177.15.3 

(To mail server dest. IP address) 

» 

Filter 

2# 

dmask 255.255.255.255 

(Set mask for exact dest. address) 

» 

Filter 

2# 

proto tcp 

(For TCP protocol traffic) 

» 

Filter 

2# 

sport any 

(From any source port) 

» 

Filter 

2# 

dport smtp 

(To a SMTP destination port) 

» 

Filter 

2# 

action allow 

(Allow matching traffic to pass) 

» 

Filter 

2# 

ena 

(Enable the filter) 

» 

Filter 

2# 

../filt 3 

(Select the menu for filter 3) 

» 

Filter 

3# 

sip 205.177.15.3 

(From mail server source IP address) 

» 

Filter 

3# 

smask 255.255.255.255 

(Set mask for exact source address) 

» 

Filter 

3# 

dip any 

(To any destination IP address) 

» 

Filter 

3# 

proto tcp 

(For TCP protocol traffic) 

» 

Filter 

3# 

sport smtp 

(From a SMTP port) 

» 

Filter 

3# 

dport any 

(To any destination port) 

» 

Filter 

3# 

action allow 

(Allow matching traffic to pass) 

» 

Filter 

3# 

ena 

(Enable the filter) 
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5. Create a filter that will allow local clients to browse the Web. 

The filter must recognize and allow TCP traffic to reach the local client destination IP addresses 
if originating from any HTTP source port: 


>> 

Filter 

3# 

.,/filt 4 

(Select the menu for Filter 4) 

>> 

Filter 

4# 

sip any 

(From any source IP address) 

>> 

Filter 

4# 

dip 205.177.15.0 

(To base local network dest. address) 

>> 

Filter 

4# 

dmask 255.255.255.0 

(For entire subnet range) 

>> 

Filter 

4# 

proto tcp 

(For TCP protocol traffic) 

>> 

Filter 

4# 

sport http 

(From any source HTTP port) 

>> 

Filter 

4# 

dport any 

(To any destination port) 

>> 

Filter 

4# 

action allow 

(Allow matching traffic to pass) 

>> 

Filter 

4# 

ena 

(Enable the filter) 

Create a filter that will allow local clients to Telnet anywhere outside the local intranet. 

The filter must 

recognize and allow TCP traffic to reach the local client destination IP 

addresses if originating from a Telnet source port: 


>> 

Filter 

4# 

../filt 5 

(Select the menu for Filter 5) 

>> 

Filter 

5# 

sip any 

(From any source IP address) 

>> 

Filter 

5# 

dip 205.177.15.0 

(To base local network dest. address) 

>> 

Filter 

5# 

dmask 255.255.255.0 

(For entire subnet range) 

>> 

Filter 

5# 

proto tcp 

(For TCP protocol traffic) 

>> 

Filter 

5# 

sport telnet 

(From a Telnet port) 

>> 

Filter 

5# 

dport any 

(To any destination port) 

>> 

Filter 

5# 

action allow 

(Allow matching traffic to pass) 

>> 

Filter 

5# 

ena 

(Enable the filter) 


7. Create a series of filters to allow Domain Name System (DNS) traffic. 

DNS traffic requires four filters; one pair is needed for UDP traffic (incoming and outgoing) 
and another pair for TCP traffic (incoming and outgoing). 
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For UDP: 


>> 

Filter 

5# 

. . /filt 6 

(Select the menu for Filter 6) 

>> 

Filter 

6# 

sip any 

(From any source IP address) 

>> 

Filter 

6# 

dip 205.177.15.4 

(To local DNS Ser\>er) 

>> 

Filter 

6# 

dmask 255.255.255.255 

(Set mask for exact dest. address) 

>> 

Filter 

6# 

proto udp 

(For UDP protocol traffic) 

>> 

Filter 

6# 

sport any 

(From any source port) 

>> 

Filter 

6# 

dport domain 

(To any DNS destination port) 

>> 

Filter 

6# 

action allow 

(Allow matching traffic to pass) 

>> 

Filter 

6# 

ena 

(Enable the filter) 

>> 

Filter 

6# 

../filt 7 

(Select the menu for Filter 7) 

>> 

Filter 

7# 

sip 205.177.15.4 

(From local DNS Server) 

>> 

Filter 

7# 

smask 255.255.255.255 

(Set mask for exact source address) 

>> 

Filter 

7# 

dip any 

(To any destination IP address) 

>> 

Filter 

7# 

proto udp 

(For UDP protocol traffic) 

>> 

Filter 

7# 

sport domain 

(From a DNS source port) 

>> 

Filter 

7# 

dport any 

(To any destination port) 

>> 

Filter 

7# 

action allow 

(Allow matching traffic to pass) 

>> 

Filter 

7# 

ena 

(Enable the filter) 


Similarly, for TCP: 


» 

Filter 

7# 

../filt 8 

(Select the menu for Filter 8) 

» 

Filter 

8# 

sip any 

(From any source IP address) 

» 

Filter 

8# 

dip 205.177.15.4 

(To local DNS Serx’er) 

» 

Filter 

8# 

dmask 255.255.255.255 

(Set mask for exact dest. address) 

» 

Filter 

8# 

proto tcp 

(For TCP protocol traffic) 

» 

Filter 

8# 

sport any 

(From any source port) 

» 

Filter 

8# 

dport domain 

(To any DNS destination port) 

» 

Filter 

8# 

action allow 

(Allow matching traffic to pass) 

» 

Filter 

8# 

ena 

(Enable the filter) 

» 

Filter 

8# 

../filt 9 

(Select the menu for Filter 9) 

» 

Filter 

9# 

sip 205.177.15.4 

(From local DNS Server) 

» 

Filter 

9# 

smask 255.255.255.255 

(Set mask for exact source address) 

» 

Filter 

9# 

dip any 

(To any destination IP address) 

» 

Filter 

9# 

proto tcp 

(For TCP protocol traffic) 

» 

Filter 

9# 

sport domain 

(From a DNS source port) 

» 

Filter 

9# 

dport any 

(To any destination port) 

» 

Filter 

9# 

action allow 

(Allow matching traffic to pass) 

» 

Filter 

9# 

ena 

(Enable the filter) 
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8. Assign the filters to the switch port that connects to the Internet. 


>> 

Filter 9# . 

/port 5 

(Select the SLB port 5 to the Internet) 

>> 

SLB 

Port 

5# 

add 1 

(Add filter 1 to port 5) 

>> 

SLB 

Port 

5# 

add 2 

(Add filter 2 to port 5) 

>> 

SLB 

Port 

5# 

add 3 

(Add filter 3 to port 5) 

>> 

SLB 

Port 

5# 

add 4 

(Add filter 4 to port 5) 

>> 

SLB 

Port 

5# 

add 5 

(Add filter 5 to port 5) 

>> 

SLB 

Port 

5# 

add 6 

(Add filter 6 to port 5) 

>> 

SLB 

Port 

5# 

add 7 

(Add filter 7 to port 5) 

>> 

SLB 

Port 

5# 

add 8 

(Addfilter 8 to port 5) 

>> 

SLB 

Port 

5# 

add 9 

(Add filter 9 to port 5) 

>> 

SLB 

Port 

5# 

add 224 

(Add the default filter to port 5) 

>> 

SLB 

Port 

5# 

filt enable 

(Enable filtering for port 5) 


9. Apply and verify the configuration. 


» SLB Port 5# apply 
» SLB Port 5# cur 

(Make your changes active) 

(View current settings) 

Examine the resulting information. If any settings are incorrect, make appropriate changes. 

Save your new configuration changes. 


>> SLB Port 5# save 

(Save for restore after reboot) 

Check the server load balancing information. 

» SLB Port 5# /info/slb/dump 

(View SLB information) 


Check that all SLB parameters are working according to expectation. If necessary, make any 
appropriate configuration changes and then check the information again. 


NOTE — Changes to filters on a given port do not take effect until the port’s session information 
is updated (every two minutes or so). To make filter changes take effect immediately, clear the 
session binding table for the port (see the / oper/sib/clear command in the Web OS 
Command Reference). 
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Network Address Translation Examples 


In the following Network Address Translation (NAT) examples, a company has configured its 
internal network with private IP addresses. A private network is one that is isolated from the 
global Internet and is, therefore, free from the usual restrictions requiring the use of registered, 
globally unique IP addresses. 

Private networks serve two main purposes: First, since private IP addresses are not valid or vis¬ 
ible outside the private network, they can increase network security; second, since valid, regis¬ 
tered IP addresses are a limited resource, many companies use private IP addresses to create 
internal networks much larger than could be created using only their official addresses. 

With NAT, private networks are not required to remain isolated. NAT capabilities within the 
switch allow internal, private network IP addresses to be translated to valid, publicly adver¬ 
tised IP addresses and back again. NAT can be configured in one of the following two ways: 

■ Static NAT provides a method for direct mapping of one predefined IP address (such as a 
publically available IP address) to another (such as a private IP address) 

■ Dynamic NAT provides a method for mapping multiple IP addresses (such as a group of 
internal clients) to a single IP address (to conserve publically advertised IP addresses) 


Static NAT 


The static NAT (non-proxy) example requires two filters: one for the external client-side 
switch port, and one for the internal, server-side switch port. The client-side filter translates 
incoming requests for the publicly advertised server IP address to the server’s internal private 
network address. The filter for the server-side switch port reverses the process, translating the 
server’s private address information to a valid public address. 

In this example, clients on the Internet require access to servers on the private network: 



Internet 





External Clients 


jr '' 


Figure 7-5 Static Network Address Translation 


128 ■ Chapter 7: Filtering 



050159A, May 2001 












Web OS 9.0 Application Guide 


This example could be configured as follows: 


>> 

# /cfg/slb/filt 10 

(Select the menu for outbound filter) 

>> 

Filter 

10# action nat 

(Perform NAT on matching traffic) 

>> 

Filter 

10# nat source 

(Translate source information) 

>> 

Filter 

10# sip 10.10.10.0 

(From the clients private IP address) 

>> 

Filter 

10# smask 255.255.255.0 

(For the entire private subnet range) 

>> 

Filter 

10# dip 205.178.13.0 

(To the public network address) 

>> 

Filter 

10# dmask 255.255.255.0 

(For the same subnet range) 

>> 

Filter 

10# ena 

(Enable the filter) 

>> 

Filter 

10# adv/proxy disable 

(Override any proxy IP settings) 

>> 

Filter 

10 Advanced# /cfg/slb/filt 11 

(Select the menu for inbound filter) 

>> 

Filter 

11# action nat 

(Use the same settings as outbound) 

>> 

Filter 

11# nat dest 

(Reverse the translation direction) 

>> 

Filter 

11# sip 10.10.10.0 

(Use the same settings as outbound) 

>> 

Filter 

11# smask 255.255.255.0 

(Use the same settings as outbound) 

>> 

Filter 

11# dip 205.178.13.0 

(Use the same settings as outbound) 

>> 

Filter 

11# dmask 255.255.255.0 

(Use the same settings as outbound) 

>> 

Filter 

11# ena 

(Enable the filter) 

>> 

Filter 

11# adv/proxy disable 

(Override any proxy IP settings) 

>> 

Filter 

11 Advanced# /cfg/slb/port 1 

(Select server-side port) 

>> 

SLB port 1# add 10 

(Add the outbound filter) 

>> 

SLB port 1# filt enable 

(Enable filtering on port 1) 

>> 

SLB port 1# ../port 2 

(Select the client-side port) 

>> 

SLB port 2# add 11 

(Add the inbound filter) 

>> 

SLB port 2# filt enable 

(Enable filtering on port 2) 

>> 

SLB port 2# apply 

(Apply configuration changes) 

>> 

SLB port 2# save 

(Save configuration changes) 


Note the following important points about this configuration: 

■ Within each filter, the smask and dmask values are identical. 

■ All parameters for both filters are identical except for the NAT direction. For Filter 10, 
nat source is used. For Filter 11, nat dest is used. 

■ Filters for static (non-proxy) NAT should take precedence over dynamic NAT filters (fol¬ 
lowing example). Static filters should be given lower filter numbers. 
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Dynamic NAT 


In this dynamic NAT example, clients on the internal private network require TCP/UDP access 
to the Internet. This is a many-to-one solution: multiple clients on the private subnet take 
advantage of a single external IP address, thus conserving valid IP addresses: 



Internet 


Internal Clients 
10.10.10.x 
(Private network) 

Figure 7-6 Dynamic Network Address Translation 

This example requires a NAT filter to be configured on the switch port connected to the inter¬ 
nal clients. When the NAT filter is triggered by outbound client traffic, the internal private IP 
address information on the outbound packets is translated to a valid, publicly advertised IP 
address on the switch. In addition, the public IP address must be configured as a proxy IP 
address on the switch port connected to the internal clients. The proxy performs the reverse 
translation, restoring the private network addresses on inbound packets. 
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This example could be configured as follows: 


>> # /cfg/slb/filt 14 

>> Filter 14# invert ena 

>> Filter 14# dip 10.10.10.0 

>> Filter 14# dmask 255.255.255.0 

>> Filter 14# sip any 

>> Filter 14# action nat 

>> Filter 14# nat source 

>> Filter 14# ena 

>> Filter 14# adv/proxy enable 

>> Filter 14 Advanced# /cfg/slb/port 1 

>> SLB port 1# add 14 

>> SLB port 1# pip 205.178.17.12 

>> SLB port 1# filt enable 

>> SLB port 1# proxy ena 

>> SLB port 1# apply 

>> SLB port 1# save 


(Select the menu for client filter) 
(Invert the filter logic) 

(If the destination is not private) 
(For the entire private subnet range) 
(From any source IP address) 
(Perform NAT on matching traffic) 
(Translate source information) 
(Enable the filter) 

(Allow PIP proxy translation) 

(Select SLB port 1) 

(Add the filter to port 1) 

(Set public IP address proxy) 
(Enable filtering on port 1) 

(Enable proxies on this port) 

(Apply configuration changes) 

(Save configuration changes) 


NOTE — The invert option in this example filter makes this specific configuration easier but 
is not a requirement for dynamic NAT. 


NOTE — Dynamic NAT solutions apply only to TCP/UDP traffic. Also, filters for dynamic 
NAT should be placed behind any static NAT filters (see “Static NAT” on page 128). Dynamic 
filters should be given higher filter numbers. 


FTP Client NAT (Active FTP for Dynamic NAT) 

Alteon Web switches provide NAT services to many clients with private IP addresses. In Web 
OS 9.0, an FTP enhancement provides the capability to perform true FTP NAT for dynamic 
NAT. 

Because of the way FTP works in active mode, a client sends information on the control chan¬ 
nel, information that reveals their private IP address, out to the Internet. However, the switch 
filter only performs NAT translation on the TCP/IP header portion of the frame, preventing a 
client with a private IP address from doing active FTP. 
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1 . 

2 . 

3. 

4. 


In Web OS, the switch can monitor the control channel and replace the client’s private IP 
address with a proxy IP address defined on the switch. When a client in active FTP mode sends 
a port command to a remote FTP server, the switch will look into the data part of the frame 
and modify the port command as follows: 

■ The real server IP address will be replaced by a public proxy IP address, using a pool of 
proxy IP addresses instead of a single one. 

■ The real server port will be replaced with a proxy port. 



Internet 


Internal Clients IUIm 

10.10.10.x 
(Private network) 

Figure 7-7 Many-to-Many NAT 

Configuring Active FTP Client Network Address Translation 

NOTE — The passive mode does not need this feature. 

Make sure that a proxy IP address is enabled on the filter port. 

Make sure that a source NAT filter is set up for the port. 

Enable active FTP NAT using the following command: 

>> # /cfg/slb/f ilt <filter number>/ a.dv/ftpa. ena 
Apply and save the switch configuration. 


1 . 

2 . 

3. 

4. 


132 ■ Chapter 7: Filtering 



050159A, May 2001 










Web OS 9.0 Application Guide 


Matching TCP Flags 

Web OS supports packet filtering based on any of the following TCP flags. 


Table 7-5 TCP Flags 


Flag 

Description 

URG 

Urgent 

ACK 

Acknowledgement 

PSH 

Push 

RST 

Reset 

SYN 

Synchronize 

FIN 

Finish 


Any filter may be set to match against more than one TCP flag at the same time. If there is 
more than one flag enabled, the flags are applied with a logical AND operator. For example, by 
setting the switch to filter SYN and ACK, the switch filters all SYN-ACK frames. 


NOTE — TCP flag filters must be cache-disabled. Exercise caution when applying cache- 
enabled and cache-disabled filters to the same switch port. For more information, see “Cache- 
Enabled versus Cache-Disabled Filters” on page 121. 


Configuring the TCP Flag Filter 


NOTE — By default, all TCP fdter options are disabled. TCP flags will not be inspected unless 
one or more TCP options are enabled. 


Consider the following network: 

— Internet 

SMTP 
Mail Server 

Figure 7-8 TCP ACK Matching Network 
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In this network, the Web servers inside the LAN must be able to transfer mail to any SMTP- 
based mail server out on the Internet. At the same time, you want to prevent access to the LAN 
from the Internet, except for HTTP. 

SMTP traffic uses well-known TCP Port 25. The Web servers will originate TCP sessions to 
the SMTP server using TCP destination Port 25, and the SMTP server will acknowledge each 
TCP session and data transfer using TCP source Port 25. 

Creating a filter with the ACK flag closes one potential security hole. Without the filter, the 
switch would permit a TCP SYN connection request to reach any listening TCP destination 
port on the Web servers inside the LAN, as long as it originated from TCP source Port 25. The 
server would listen to the TCP SYN, allocate buffer space for the connection, and reply to the 
connect request. In some SYN attack scenarios, this could cause the server’s buffer space to 
fill, crashing the server or at least making it unavailable. 

A filter with the ACK flag enabled prevents external devices from beginning a TCP connection 
(with a TCP SYN) from TCP source Port 25. The switch drops any frames that have the ACK 
flag turned off. 

The following filters are required: 

1. A filter that allows the Web servers to pass SMTP requests to the Internet. 


>> 

# /cfg/slb/filt 

10 

>> 

Filter 

10# 

sip 203.122.186.0 

>> 

Filter 

10# 

smask 

255.255.255 

>> 

Filter 

10# 

sport 

any 

>> 

Filter 

10# 

proto 

tcp 

>> 

Filter 

10# 

dip any 

>> 

Filter 

10# 

dport 

smtp 

>> 

Filter 

10# 

action allow 

>> 

Filter 

10# 

ena 



(Select a filter for trusted SMTP requests) 

(From the Web servers’ source IP address) 
(For the entire subnet range) 

(From any source port) 

(For TCP traffic) 

(To any destination IP address) 

(To well-known destination SMTP port) 
(Allow matching traffic to pass) 

(Enable the filter) 
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2. A filter that allows SMTP traffic from the Internet to pass through the switch only if the 
destination is one of the Web servers, and the frame is an acknowledgment (ACK) of a 
TCP session. 


>> 

Filter 

10# 

. ,/filt 15 

(Select a filter for Internet SMTP ACKs) 

>> 

Filter 

15# 

sip any 

(From any source IP address) 

>> 

Filter 

15# 

sport smtp 

(From well-known source SMTP port) 

>> 

Filter 

15# 

proto top 

(For TCP traffic) 

>> 

Filter 

15# 

dip 203.122.186.0 

(To the Web servers ' IP address) 

>> 

Filter 

15# 

dmask 255.255.255.0 

(To the entire subnet range) 

>> 

Filter 

15# 

dport any 

(To any destination port) 

>> 

Filter 

15# 

action allow 

(Allow matching traffic to pass) 

>> 

Filter 

15# 

ena 

(Enable the filter) 

>> 

Filter 

15# 

adv/tcp 

(Select the advanced TCP menu) 

>> 

Filter 

15 Advanced# ack ena 

(Match acknowledgments only) 

A filter that allows trusted HTTP traffic from the Internet to pass through the switch to 

the Web servers. 



>> 

Filter 

15 Advanced# /cfg/slb/filt 

16 (Select a filter for incoming HTTP traffic) 

>> 

Filter 

16# 

sip any 

(From any source IP address) 

>> 

Filter 

16# 

sport http 

(From well-known source HTTP port) 

>> 

Filter 

16# 

proto tcp 

(For TCP traffic) 

>> 

Filter 

16# 

dip 203.122.186.0 

(To the Web servers’ IP address) 

>> 

Filter 

16# 

dmask 255.255.255.0 

(To the entire subnet range) 

>> 

Filter 

15# 

dport http 

(To well-known destination HTTP port) 

>> 

Filter 

16# 

action allow 

(Allow matching traffic to pass) 

>> 

Filter 

16# 

ena 

(Enable the filter) 

A filter that allows HTTP responses from the Web servers to pass through the switch to 

the Internet. 




>> 

Filter 

16# 

. ./filt 17 

(Select a filter for outgoing HTTP traffic) 

» 

Filter 

17# 

sip 203.122.186.0 

(From the Web servers’ source IP address) 

>> 

Filter 

17# 

smask 255.255.255.0 

(From the entire subnet range) 

>> 

Filter 

17# 

sport http 

(From well-known source HTTP port) 

>> 

Filter 

17# 

proto tcp 

(For TCP traffic) 

>> 

Filter 

17# 

dip any 

(To any destination IP address) 

>> 

Filter 

17# 

dport http 

(To well-known destination HTTP port) 

>> 

Filter 

17# 

action allow 

(Allow matching traffic to pass) 

» 

Filter 

17# 

ena 

(Enable the filter) 
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5. A default filter is required to deny all other traffic. 


>> 

Filter 

17# 

,/filt 224 

(Select a default filter) 

>> 

Filter 

224# 

sip any 

(From any source IP address) 

>> 

Filter 

224# 

dip any 

(To any destination IP address) 

>> 

Filter 

224# 

action deny 

(Block matching traffic) 

>> 

Filter 

224# 

ena 

(Enable the filter) 


6. Apply the filters to the appropriate switch ports. 


» 

Filter 22 

4# 

../port 1 

(Select the Internet-side port) 

» 

SLB 

port 

1# 

add 15 

(Add the SMTP ACK filter to the port) 

» 

SLB 

port 

1# 

add 16 

(Add the incoming HTTPS filter) 

» 

SLB 

port 

1# 

add 224 

(Add the default filter to the port) 

» 

SLB 

port 

1# 

filt ena 

(Enable filtering on the port) 

» 

SLB 

port 

1# 

../port 2 

(Select the first Web server port) 

» 

SLB 

port 

2# 

add 10 

(Add the outgoing SMTP filter to the port) 

» 

SLB 

port 

2# 

add 17 

(Add the outgoing HTTP filter to the port) 

» 

SLB 

port 

2# 

add 224 

(Add the default filter to the port) 

» 

SLB 

port 

2# 

filt ena 

(Enable filtering on the port) 

» 

SLB 

port 

2# 

../port 3 

(Select the other Web server port) 

» 

SLB 

port 

3# 

add 10 

(Add the outgoing SMTP filter to the port) 

» 

SLB 

port 

3# 

add 17 

(Add the outgoing HTTP filter to the port) 

» 

SLB 

port 

3# 

add 224 

(Add the default filter to the port) 

» 

SLB 

port 

3# 

filt ena 

(Enable filtering on the port) 

» 

SLB 

port 

3# 

apply 

(Apply the configuration changes) 

» 

SLB 

port 

3# 

save 

(Save the configuration changes) 
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Matching ICMP Message Types 


Internet Control Message Protocol (ICMP) is used for reporting TCP/IP processing errors. 
There are numerous types of ICMP messages, as shown in Table 7-6. Although ICMP packets 
can be filtered using the proto icmp option, by default, the Web switch ignores the ICMP 
message type when matching a packet to a filter. To perform filtering based on specific ICMP 
message types, ICMP message type filtering must be enabled. 

Web OS software supports filtering on the following ICMP message types: 

Table 7-6 ICMP Message Types 

Type # 

Message Type 

Description 

0 

echorep 

ICMP echo reply 

3 

destun 

ICMP destination unreachable 

4 

quench 

ICMP source quench 

5 

redir 

ICMP redirect 

8 

echoreq 

ICMP echo request 

9 

rtradv 

ICMP router advertisement 

10 

rtrsol 

ICMP router solicitation 

11 

timex 

ICMP time exceeded 

12 

param 

ICMP parameter problem 

13 

timereq 

ICMP timestamp request 

14 

timerep 

ICMP timestamp reply 

15 

inforeq 

ICMP information request 

16 

inforep 

ICMP information reply 

17 

maskreq 

ICMP address mask request 

18 

maskrep 

ICMP address mask reply 


Alteon ((^Systems Chapter 7: Filtering *137 

050159A, May 2001 






Web OS 9.0 Application Guide 


The command to enable or disable ICMP message type filtering is entered from the Advanced 
Filtering menu as follows: 


>> # /cfg/slb/filt <filternumber>/ adv 

>> Filter 1 Advanced# icmp <message type\number\any | list> 


For any given filter, only one ICMP message type can be set at any one time. The any option 
disables ICMP message type filtering. The list option displays a list of the available ICMP 
message types that can be entered. 


NOTE — ICMP message type filters must be cache-disabled. Exercise caution when applying 
cache-enabled and cache-disabled filters to the same switch port. For more information, see 
“Cache-Enabled versus Cache-Disabled Filters” on page 121. 
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Application Redirection 


Application Redirection improves network bandwidth and provides unique network solutions. 

Filters can be created to redirect traffic to cache and application servers improving speed of 

access to repeated client access to common Web or application content and freeing valuable 

network bandwidth. 

The following topics are discussed in this chapter: 

■ “Overview” on page 140. Application redirection helps reduce the traffic congestion dur¬ 
ing peak loads by accessing locally cached information. This section also discusses how 
performance is improved by balancing cached Web requests across multiple servers. 

■ “Web Cache Configuration Example” on page 142. This section provides a step-by-step 
procedure on how to intercept all Internet bound HTTP requests (on default TCP port 80) 
and redirect them to the Web cache servers. 

■ “IP Proxy Addresses for Network Address Translation” on page 147. This section dis¬ 
cusses the benefits of transparent proxies when used with application redirection. 

■ “Excluding Noncacheable Sites” on page 149. This section describes how to filter out 
applications that keep real-time session information from being redirected to cache serv¬ 
ers. 


NOTE — To access Application Redirection functionality, the optional Layer 4 software must 
be enabled on the Web switch (see “Filtering and Layer 4” in Chapter 8 of the Web OS 9.0 
Command Reference). 
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Overview 


Much of the information downloaded from the Internet is not unique, as clients will often 
access the Web page many times for additional information or to explore other links. Duplicate 
information also gets requested as the components that make up Internet data at a particular 
Web site (pictures, buttons, frames, text, and so on) are reloaded from page to page. When you 
consider this scenario in the context of many clients, it becomes apparent that redundant 
requests can consume a considerable amount of your available bandwidth to the Internet. 

Application redirection can help reduce the traffic congestion during peak loads. When Appli¬ 
cation redirection filters are properly configured for the Web OS-powered switch, outbound 
client requests for Internet data are intercepted and redirected to a group of application or Web 
cache servers on your network. The servers duplicate and store inbound Internet data that has 
been requested by your clients. If the servers recognize a client’s outbound request as one that 
can be filled with cached information, the servers supply the information rather than send the 
request across the Internet. 

In addition to increasing the efficiency of your network, accessing locally cached information 
can be much faster than requesting the same information across the Internet. 


Web Cache Redirection Environment 


Consider a network where client HTTP requests begin to regularly overload the Internet router. 



Congestion 
Targets Router 


Internet 


Figure 8-1 Traditional Network Without Web Cache Redirection 
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The network needs a solution that addresses the following key concerns: 

■ The solution must be readily scalable 

■ The administrator should not need to reconfigure all the clients’ browsers to use proxy 
servers. 



Figure 8-2 Network with Web Cache Redirection 
Adding an Alteon Web switch with optional Layer 4 software addresses these issues: 

■ Web cache servers can be added or removed dynamically without interrupting services. 

■ Performance is improved by balancing the cached Web request load across multiple serv¬ 
ers. More servers can be added at any time to increase processing power. 

■ The proxy is transparent to the client. 

■ Frames that are not associated with HTTP requests are normally passed to the router. 

Additional Application Redirection Options 

Application redirection can be used in combination with other Layer 4 options, such as load 
balancing metrics, health checks, real server group backups, and more. See “Additional Server 
Load Balancing Options” on page 78 for details. 
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Web Cache Configuration Example 


The following is required prior to configuration: 

■ You must connect to the Web switch Command Line Interface (CLI) as the administrator. 

■ Optional Layer 4 software must be enabled. 


NOTE — For details about the procedures above, and about any of the menu commands 
described in this example, see the Web OS Command Reference. 


In this example, an Alteon Web switch is placed between the clients and the border gateway to 
the Internet. The Web switch will be configured to intercept all Internet bound HTTP requests (on 
default TCP port 80), and redirect them to the Web cache servers. The Web switch will distribute 
HTTP requests equally to the Web cache servers based on the destination IP address of the 
requests. 

Also, filters are not limited to the few protocols and TCP or UDP applications shown in this 
example. See Table 7-1 on page 116 and Table 7-2 on page 117 for a list of other well-known 
protocols and services. 

1. Assign an IP address to each of the Web cache servers. 

Similar to server load balancing, the Web cache real servers are assigned an IP address and 
placed into a real server group. The real servers must be in the same VLAN and must have an 
IP route to the Web switch that will perform the Web cache redirection. In addition, the path 
from the Web switch to the real servers must not contain a router. The router would stop HTTP 
requests from reaching the Web cache servers and, instead, directing them back out to the 
Internet. 

More complex network topologies can be used if configuring IP proxy addresses (see “IP 
Proxy Addresses for Network Address Translation” on page 147). 

For this example, the three Web cache real servers have the following IP addresses on the same 
IP subnet: 

Table 8-1 Web Cache Example: Real Server IP Addresses 


Web Cache Server 

IP address 

Server A 

200.200.200.2 

Server B 

200.200.200.3 

Server C 

200.200.200.4 
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2. Install transparent Web cache software on all three Web cache servers. 

3. Define an IP interface on the Web switch. 

Since, by default, the Web switch only remaps destination MAC addresses, it must have an IP 
interface on the same subnet as the three Web cache servers. 

To configure an IP interface for this example, enter this command from the CLI: 


>> 

# 

/cfg/ip/if 

1 

(Select IP interface 1) 

>> 

IP 

Interface 

1# addr 200.200.200.100 

(Assign IP address for the interface) 

>> 

IP 

Interface 

1# ena 

(Enable IP interface 1) 


NOTE — The IP interface and the real servers must be in the same subnet. This example 
assumes that all ports and IP interfaces use default VLAN 1, requiring no special VLAN con¬ 
figuration for the ports or IP interface. 

4. Define each real server. 

For each Web cache real server, you must assign a real server number, specify its actual IP 
address, and enable the real server. For example: 


» 

ip# 

/cfg/slb/real 1 

(SeryerA is real server 1) 

» 

Real 

server 

i# 

rip 200.200.200.2 

(Assign SeryerA IP address) 

» 

Real 

server 

i# 

ena 

(Enable real server 1) 

» 

Real 

server 

i# 

../real 2 

(Seryer B is real server 2) 

» 

Real 

server 

2# 

rip 200.200.200.3 

(Assign Server B IP address) 

» 

Real 

server 

2# 

ena 

( Enable real server 2) 

» 

Real 

server 

2# 

.. / real 3 

(Seryer C is real sen’er 3) 

» 

Real 

server 

3# 

rip 200.200.200.4 

(Assign Sen’er C IP address) 

» 

Real 

server 

3# 

ena 

(Enable real sen’er 3) 


5. Define a real server group. 

This places the three Web cache real servers into one service group: 


» 

Real 

server 

3# . . 

/group 1 


(Select reed sen’er group 1) 

» 

Real 

server 

group 

1# 

add 

1 

(Add real sen’er 1 to group 1) 

» 

Real 

server 

group 

1# 

add 

2 

(Add real sen’er 2 to group 1) 

» 

Real 

server 

group 

1# 

add 

3 

(Add real sen’er 3 to group 1) 
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6. Set the real server group metric to minmisses. 

This setting helps minimize Web cache misses in the event real servers fail or are taken out of 
service: 

>> Real server group 1# metric minmisses (Metric for minimum cache misses.) 

7. Verify that server processing is disabled on the ports supporting application redirection. 


NOTE — Do not use the “server” setting on a port with Application Redirection enabled. Server 
processing is used only with SLB. To disable server processing on the port, use the commands 
on the / cf g/slb/port menu, as described in Chapter 8 of the Web OS 9.0 Command Refer¬ 
ence. 


8. Create a filter that will intercept and redirect all client HTTP requests. 

The filter must be able to intercept all TCP traffic for the HTTP destination port and must redi¬ 
rect it to the proper port on the real server group: 


>> 

SLB port 

6# /cfg/slb/filt 2 

(Select the menu for Filter 2) 

>> 

Filter 

2# 

sip any 

(From any source IP addresses) 

>> 

Filter 

2# 

dip any 

(To any destination IP addresses) 

>> 

Filter 

2# 

proto top 

(For TCP protocol traffic) 

>> 

Filter 

2# 

sport any 

(From any source port) 

>> 

Filter 

2# 

dport http 

(To an HTTP destination port) 

>> 

Filter 

2# 

action redir 

(Set the action for redirection) 

>> 

Filter 

2# 

rport http 

(Set the redirection port) 

>> 

Filter 

2# 

group 1 

(Select real server group 1) 

>> 

Filter 

2# 

ena 

(Enable the filter) 


The rport parameter must be configured whenever TCP/UDP protocol traffic is redirected. 
The rport parameter defines the real server TCP or UDP port to which redirected traffic will 
be sent. The port defined by the rport parameter is used when performing Layer 4 health 
checks of TCP services. 

Also, if NAT and proxy addresses are used on the Web switch (see Step 3 on page 143), the 
rport parameter must be configured for all application redirection filters. Take care to use 
the proper port designation with rport: if the transparent proxy operation resides on the host, 
the well-known port (80 or “http”) is probably required. If the transparent proxy occurs on the 
Web switch, make sure to use the service port required by the specific software package. 

See “IP Proxy Addresses for Network Address Translation” on page 147 for more about IP 
proxy addresses. 
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9. Create a default filter. 

In this case, the default filter will allow all noncached traffic to proceed normally: 


>> 

Filter 

2# . 

/filt 224 

(Select the default filter) 

>> 

Filter 

224# 

sip any 

(From any source IP addresses) 

>> 

Filter 

224# 

dip any 

(To any destination IP addresses) 

>> 

Filter 

224# 

proto any 

(For any protocols) 

>> 

Filter 

224# 

action allow 

(Set the action to allow traffic) 

>> 

Filter 

224# 

ena 

(Enable the default filter) 


NOTE — When the proto parameter is not tcp or udp, then sport and dport are ignored. 


10. Assign the filters to the client ports. 

Assuming that the redirected clients are connected to physical switch Ports 5 and 6, both ports 
are configured to use the previously created filters as follows: 


» 

Filter 224# 

../port 5 

(Select the SLB port 5) 

» 

SLB 

Port 

5# 

add 2 

(Add filter 1 to port 5) 

» 

SLB 

Port 

5# 

add 224 

(Add the default filter to port 5) 

» 

SLB 

Port 

5# 

filt enable 

(Enable filtering for port 5) 

» 

SLB 

Port 

5# 

../port 6 

(Select the SLB port 6) 

» 

SLB 

Port 

6# 

add 2 

(Add filter 1 to port 6) 

» 

SLB 

Port 

6# 

add 224 

(Add the default filter to port 6) 

» 

SLB 

Port 

6# 

filt enable 

(Enable filtering for port 6) 


11. Enable, apply, and verify the configuration. 


» 

SLB Port 

6# /cfg/slb 

(Select Server Load Balancing Menu) 

» 

Layer 

4# 

on 

(Activate Layer 4 software sendees) 

» 

Layer 

4# 

apply 

(Make your changes active) 

» 

Layer 

4# 

cur 

(View current settings) 


NOTE — SLB must be turned on in order for application redirection to work properly. The on 
command is valid only if the optional Layer 4 software is enabled on your Web switch (see 
“Activating Optional Software” in the Web OS Command Reference). 


12. Examine the resulting information from the cur command. If any settings are incorrect, 
make appropriate changes. 
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13. Save your new configuration changes. 


>> Layer 4# save 


(Save for restore after reboot) 


14. Check the SLB information. 


>> Layer 4# /info/slb 


(View SLB information) 


Check that all SLB parameters are working according to expectation. If necessary, make any 
appropriate configuration changes and then check the information again. 


NOTE — Changes to filters on a given port only effect new sessions. To make fdter changes 
take effect immediately, clear the session binding table for the port (see the 
/ oper/sib/clear command in the Web OS Command Reference ). 


Delayed Binding for Web Cache Redirection 

To configure delayed binding on your Web switch for WCR only, use the following command: 


>> # /cfg/slb/f ilt <filter number>/ adv/urlp ena 


For more conceptual information on delayed binding, see “Delayed Binding” on page 96. 
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IP Proxy Addresses for Network Address 
Translation 


Transparent proxies provide the benefits listed below when used with application redirection. 

Application redirection is automatically enabled when a filter with the redi r action is applied 

on a port. 

■ With proxies IP addresses configured on redirected ports, the Web switch can redirect cli¬ 
ent requests to servers located on any subnet, anywhere. 

■ The Web switch can perform transparent substitution for all source and destination 
addresses, including destination port remapping. This provides support for comprehen¬ 
sive, fully-transparent proxies. These proxies are transparent to the user. No additional cli¬ 
ent configuration is needed. 

The following procedure can be used for configuring proxy IP addresses: 

1. Add proxy IP addresses to the redirection ports. 

Each of the ports using redirection filters require proxy IP addresses to be configured. Each 

proxy IP address must be unique on your network. These are configured as follows: 


>> 

SLB 

port 

3# 

/cfg/slb/port 5 

(Select network port 5) 

>> 

SLB 

port 

5# 

pip 200.200.200.68 

(Set proxy IP address for port 5) 

>> 

SLB 

port 

5# 

proxy ena 

(Enable proxy port 5) 

>> 

SLB 

port 

5# 

../port 6 

(Select network port 6) 

>> 

SLB 

port 

6# 

pip 200.200.200.69 

(Set proxy IP address for port 6) 

>> 

SLB 

port 

6# 

proxy ena 

(Enable proxy port 6) 


2. If VMA is enabled, add proxy IP addresses for all other switch ports (except port 9). 

Virtual Matrix Architecture (VMA) is normally enabled on the Web switch. In addition to 
enhanced resource management, this feature eliminates many of the restrictions found in ear¬ 
lier versions of the Web OS. It does require, however, that when any switch port is configured 
with an IP proxy address, all ports must be configured with IP proxy addresses. Otherwise, if 
VMA is disabled, only the client port with filters need proxy IP addresses and this step can be 
skipped. 
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The following commands can be used to configure the additional unique proxy IP addresses: 


>> 

SLB 

port 

6# 

../port 1 

(Select network port 1) 

>> 

SLB 

port 

1# 

pip 200.200.200.70 

(Set proxy IP address for port 1) 

>> 

SLB 

port 

1# 

. . /port 2 

(Select network port 2) 

>> 

SLB 

port 

2# 

pip 200.200.200.71 

(Set proxy IP address for port 2) 

>> 

SLB 

port 

2# 

../port 3 

(Select network port 3) 

>> 

SLB 

port 

3# 

pip 200.200.200.72 

(Set proxy IP address for port 3) 

>> 

SLB 

port 

3# 

../port 4 

(Select network port 4) 

>> 

SLB 

port 

4# 

pip 200.200.200.73 

(Set proxy IP address for port 4) 

>> 

SLB 

port 

4# 

. . /port 7 

(Select network port 7) 

>> 

SLB 

port 

7# 

pip 200.200.200.74 

(Set proxy IP address for port 7) 

>> 

SLB 

port 

7# 

../port 8 

(Select network port 8) 

>> 

SLB 

port 

8# 

pip 200.200.200.75 

(Set proxy IP address for port 8) 


NOTE — Port 9 does not require a proxy IP address with VMA enabled. 


See the Web OS Command Reference for more information (/ cfg/sib/adv/matrix). 

3. Configure the Application Redirection filters. 

Once proxy IP addresses are established, configure each Application Redirection filter (Filter 2 
in our example) with the real server TCP or UDP port to which redirected traffic will be sent. 
In this case, the requests are mapped to a different destination port (8080). You must also 
enable proxies on the real servers: 


>> # /cfg/slb/filt 2 
>> Filter 2# rport 8080 

>> Filter 2# real 1/proxy enable 

>> Real server 1# ../real 2/proxy enable 

>> Real server 2# ../real 3/proxy enable 


(Select the menu for Filter 2) 
(Set proxy redirection port) 
(Enable proxy on real servers) 
(Enable proxy on real servers) 
(Enable proxy on real servers) 


NOTE — This configuration is not limited to HTTP Web service. Other TCP/IP services can be 
configured in a similar fashion. For example, if this had been a DNS redirect, rport would be 
sent to well-known port 53 (or the service port you want to remap to). For a list of other well- 
known services and ports, see the Web OS 8.3 Command Reference. 


4. Apply and save your changes. 

5. Check server statistics to verify that traffic has been redirected based on filtering criteria: 


>> # /info/slb/group <group number>/ filter <filter number> 
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Excluding Noncacheable Sites 


Some Web sites provide content that is not well suited for redirection to cache servers. Such 
sites might provide browser-based games or applications that keep real-time session informa¬ 
tion or authenticate by client IP address. 

To prevent such sites from being redirected to cache servers, create a filter which allows this 
specific traffic to pass normally through the Web switch. This filter must have a higher prece¬ 
dence (a lower filter number) than the application redirection filter. 

For example, if you wished to prevent a popular Web-based game site on subnet 200.10.10.* 
from being redirected, you could add the following to the previous example configuration: 


>> 

# /cfg/slb/filt 1 

(Select the menu for filter 1) 

» 

Filter 

1# dip 200.10.10.0 

(To the site’s destination IP address) 

>> 

Filter 

1# dmask 255.255.255.0 

(For entire subnet range) 

>> 

Filter 

1# sip any 

(From any source IP address) 

>> 

Filter 

1# proto tcp 

(For TCP traffic) 

» 

Filter 

1# dport http 

(To an HTTP destination port) 

>> 

Filter 

1# sport any 

(From any source port) 

>> 

Filter 

1# action allow 

( Allow matching traffic to pass) 

>> 

Filter 

1# ena 

(Enable the filter) 

>> 

Filter 

1# ../port 5 

( Select SLB port 5 ) 

>> 

SLB port 5# add 1 

(Add the filter to port 5) 

>> 

SLB port 5# ../port 6 

(Select SLB port 6) 

>> 

SLB port 6# add 1 

(Add the filter to port 6) 

>> 

SLB port 6# apply 

(Apply configuration changes) 

>> 

SLB port 6# save 

(Save configuration changes) 
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Virtual Matrix Architecture 


Virtual Matrix Architecture (VMA) is a hybrid architecture that takes full advantage of the dis¬ 
tributed processing capability in Alteon Web switches. With VMA, the switch makes optimal 
use of system resources by distributing the workload to multiple processors, thereby improving 
switch performance and increasing session capacity. VMA also removes the topology con¬ 
straints introduced by using Direct Access Mode (DAM). 

The number of concurrent sessions per switch, with VMA enabled, is given below: 

■ AD4 and A184: 512K 

■ AD3 and A180E: 336K 

■ AD2:256K 

For better switch performance and higher session capacities, it is recommended that you 
enable VMA, especially when using Bandwidth Management and Content Intelligent Switch¬ 
ing for multiple frames processing (up to 4500 bytes). 

Proxy IP Addresses and VMA 

By default, VMA is enabled on the Web switch (/cfg/slb/adv/matrix). If you are 
upgrading to Web OS 9.0 from a previous release, however, VMA will be initially disabled if a 
proxy IP address is configured for any port on the switch. VMA requires that if any port is con¬ 
figured with a proxy IP address, then all ports (except port 9) must be configured with a unique 
proxy IP address prior to enabling VMA. 

With VMA, the concept of a per-port session table doesn’t apply; instead, there is a global ses¬ 
sion table. To identify which processor should process responses to proxied requests, a unique 
proxy IP address must be configured on each port (except port 9). The action of the unused 
proxy IP addresses can be disabled using /cfg/slb/port x/proxy dis. 
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Frames ingressing a port that has been configured with a proxy IP address and the proxy 
option enabled (/cf g/s lb/port x/proxy ena) can be processed using a proxy IP 
address by any switch port, that is, the client source address will be substituted with the proxy 
IP address on the port processing the request. Frames ingressing switch ports that have been 
configured with a proxy IP address but do not have the proxy option enabled can be pro¬ 
cessed by other ports configured with a proxy IP address, but the client source address will not 
be replaced with a proxy IP address before being forwarded to a server. 


>> 

# 

/cfg/slb/port 

l/pip 

10.10.10.10 


>> 

# 

/cfg/slb/port 

1/pip 

10.10.10.ll/proxy 

ena 

>> 

# 

/cfg/slb/port 

2/pip 

10.10.10.ll/proxy 

dis 

>> 

# 

/cfg/slb/port 

3/pip 

10.10.10.12/proxy 

dis 

>> 

# 

/cfg/slb/port 

4/pip 

10.10.10.13/proxy 

dis 

>> 

# 

/cfg/slb/port 

5/pip 

10.10.10.14/proxy 

dis 

and so 

on.... 





(Proxy IP for NAT, etc.) 
(Turns on address proxying) 
(Turns off address proxying) 


NOTE — VMA must be enabled if you are setting up Firewall Load Balancing (FWLB) with 
clean-side switches performing server load balancing (SLB) or URL-based SLB and Direct 
Access Mode (DAM) is enabled. 
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Health Checking 


Content intelligent Web switches allow Webmasters to customize server health checks to ver¬ 
ify content accessibility in large Web sites. As the amount of content grows and information is 

distributed across different server farms, flexible, customizable content health checks are criti¬ 
cal to ensure end-to-end availability. 

The following Web OS health-checking topics are described in this chapter: 

■ “Health Check Types” on page 154. This section describes the different types of health 
checking: TCP and application-specific health checks, ASCII script-based health checks, 
and ICMP health check. 

■ “Real Server Health Checks” on page 156. This section explains the switch’s default 
health check which checks the status of each service on each real server every two sec¬ 
onds. 

■ “Host name for HTTP Content Health Checks” on page 156. This section provides exam¬ 
ples of HTTP-based health checks using hostnames. 

■ “IMAP Server Health Checks” on page 158. This section describes how the mail server 
protocol is used to perform health checking between a client system and a mail server. 

■ “RADIUS Server Health Checks” on page 158. This section explains how the RADIUS 
protocol is used to authenticate dial-up users to Remote Access Servers (RASs). 

■ “HTTPS/SSL Health Check” on page 159. This section explains how the switch queries 
the health of the SSL servers by sending an SSL client “Hello” packet and then verifies the 
contents of the server’s “Hello” response. 

■ “WAP Health Checks” on page 160. This section discusses how the Web switch provides a 
connectionless WSP health check for WAP gateways. 

■ “Script-Based Health Checks” on page 163. This section describes how to configure the 
switch to send a series of health-check requests to real servers or real server groups and 
monitor the responses. 

■ “Failure Types” on page 168. This section explains the service failed and server failed 
states. 
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Health Check Types 


Web OS includes support for health checks availability of real server, TCP, and ICMP. Appli¬ 
cation-specific health checks and ASCII script-based health checks are also available. Each 
health check type is summarized below. 

Real Server Health Checks 

Alteon Web switches running Server Load Balancing (SLB) monitor the servers in the real 
server group and the load-balanced application(s) running on them. If a server or application 
fails to respond to a specified number of health checks, the switch will not direct any new con¬ 
nection requests to that server. For information on setting real server health checking parame¬ 
ters, see “Real Server Health Checks” on page 156. 

TCP Health Checks 

TCP health checks are useful in verifying TCP applications that cannot be scripted. Session 
switches monitor the health of servers and applications by sending Layer 4 connection requests 
(TCP SYN packets) for each load-balanced TCP service to each server in the server group on a 
regular basis. The rate at which these connection requests are sent is a user-configurable 
parameter. These connection requests identify both failed servers and failed services on a 
healthy server. When a connection request succeeds, the session switch quickly closes the con¬ 
nection by sending a TCP FIN packet. 

ICMP Health Checks 

The Layer 3 echo - echo reply health check is used for UDP services or when ICMP health 
checks are configured. 
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Application-Specific Health Checks 

These health checks include the following applications: 

■ HTTP 

■ FTP 

■ SMTP 

■ POP3 

■ IMAP 

■ NNTP 

■ RADIUS 

The Web switch can check availability of Remote Access Dial-In User Service (RADIUS) 
content and SSL connections. 

■ SSL “Hello” Health Checks 

A health-check option on the Real Server Group Menu 

(/cf g/slb/group/healt/sslh) allows the switch to query the health of SSL serv¬ 
ers. 

■ Wireless Application Protocol (WAP) 

WAP is a protocol that allows Web services to be delivered to mobile phones and hand¬ 
sets. The translation from HTTP/HTML to WAP/WML (Wireless Markup Language) is 
implemented by servers known as WAP gateways. WAP devices can communicate either 
in the unencrypted Wireless Session Protocol (WSP) mode or an encrypted Wireless 
Transport Layer Security (WTLS) mode. 

Script-Based Health Checks 

The “send/expect” script-based health checks dynamically verify application and content 
availability using scripts. These scripts execute a sequence of tests to verify application and 
content availability. For more information, see “Script-Based Health Checks” on page 163. 
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Real Server Health Checks 


Alteon Web switches running Server Load Balancing (SLB) monitor the servers in the real 
server group and the load-balanced application(s) running on them. If a session switch detects 
that a server or application has failed, it will not direct any new connection requests to that 
server. When a service fails, an Alteon Web switch can remove the individual service from the 
load-balancing algorithm without affecting other services provided by that server. 

By default, the Web switch checks the status of each service on each real server every two sec¬ 
onds. Sometimes, the real server may be too busy processing connections to respond to health 
checks. If a service does not respond to four consecutive health checks, the switch, by default, 
declares the service unavailable. You can modify both the health check interval and the number 
of retries. 


>> # /cfg/slb/real <real server number> 
» Real server# inter 4 
>> Real server# retry 6 


(Select the real ser\<er) 

(Check real server every 4 seconds) 
(If 6 consecutive health checks fail, 
declare real server down) 


NOTE — Health checks are performed sequentially when used in conjunction with a virtual 
server configured with multiple services and groups. As a result, the actual health-check inter¬ 
val could vary significantly from the value set for it using the inter parameter. 


Host name for HTTP Content Health Checks 


HTTP-based health checks can include the hostname for HOST : headers. The HOST : header 
and health check URL are constructed from the following components: 


Item 

Option 

Configured Under 

Max. Length 

Virtual server hostname 

hname 

/cfg/slb/virt/service 

9 characters 

Domain name 

dname 

/cfg/slb/virt 

35 characters 

Server group health check field 

content 

/cfg/slb/group 

34 characters 


If the HOST : header is required, an HTTP/1.1 GET will occur, otherwise, an HTTP/1.0 
GET will occur. 
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Example 1: 

hname = everest 

dname = alteonwebsystems.com 

content = index.html 

Health check is performed using: 

GET /index.html HTTP/1.1 

Host: everest. alteonwebsystems . com 

Example 2: 

hname = (none) 

dname = raleighduram.cityguru.com 
content = /page/gen/?_template=alteon 

Health check is performed using: 

GET /page/gen/?_template=alteon HTTP/1.1 
Host: raleighduram.cityguru.com 

Example 3: 

hname = (none) 

dname = jansus 
content = index.html 

Health check is performed using: 

GET /index.html HTTP/1.1 
Host: jansus 

Example 4: 

hname = (none) 
dname = (none) 

content = index.html 

Health check is performed using: 

GET /index.html HTTP/1.0 (since no HTTP HOST : header is required) 

Example 5: 

hname = (none) 
dname = (none) 

content = / /everest/index.html 

Health check is performed using: 

GET /index.html HTTP/1.1 
Host: everest 
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IMAP Server Health Checks 


Internet Message Access Protocol (IMAP) is a mail server protocol used between a client sys¬ 
tem and a mail server that allows a user to retrieve and manipulate mail messages. IMAP is not 
used for mail transfers between mail servers. 

IMAP servers listen to TCP port 143. To support IMAP health checking, the network adminis¬ 
trator must configure a username .password value in the switch, using the content option on 
the SLB Real Server Group Menu (/cfg/slb/group). 


» # 

/cf g/sib/group deal server group number> 

(Select the real server group) 

» # 

slb/group/health imap 

(Specify the type of health checking to 



be performed) 

» # 

. . /content <username> : <password> 

(Specify IMAP username .-password) 


The content option specifies the username:password value that the server tries to match in 
its user database. In addition to verifying the user name and password, the database may spec¬ 
ify the client(s) or port(s) the user is allowed to access. 


RADIUS Server Health Checks 


The Remote Authentication Dial-In User Service (RADIUS) protocol is used to authenticate 
dial-up users to Remote Access Servers (RASs) and the client application they will use during 
the dial-up connection. 

■ RADIUS Content Health Check Enhancements 

□ Include the switch IP as the NAS IP parameter in the RADIUS content health check 

□ RADIUS health check using the configured real server port (rport) 

□ Variable-length RADIUS secret password. Supports less than 16 octets and up to 32 
octets 

■ The secret value is a field of up to 32 alphanumeric characters used by the switch to 
encrypt a password during the RSA Message Digest Algorithm (MD5) and by the 
RADIUS server to decrypt the password during verification. 

■ The content option specifies the username .-password value that the server tries to 
match in its user database. In addition to verifying the user name and password, the data¬ 
base may specify the client(s) or port(s) the user is allowed to access. 
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RADIUS Secret and Password Configuration 

RADIUS is stateless and uses UDP as its transport protocol. To support RADIUS health 
checking, the network administrator must configure two parameters on the switch: the 
/cf g/slb/secret value and the content parameter with a username .-password value. 


» 

» 

» 

» 


# 

# 

# 

# 


/cf g/sib/group <real sewer group number> 

health radius 

content <username> : <password> 

/cf g/sib/adv/secret <RADIUS-coded value> 


(Select the real server group) 

(Specify the type of health checking) 
(Specify the RADIUS username.-pass- 
word value) 

(Enter up to 32 alphanumeric charac¬ 
ters used to encrypt and decrypt pass¬ 
word) 


RADIUS Server Content Health Checks 

The Alteon Web switch will provide the NAS IP parameter while performing RADIUS content 
health checks. The switch uses the IP address of the IP interface that is on the same subnet as 
the RADIUS server or the default gateway as the NAS IP. 


NOTE — Although the NAS IP is not specified as being required in the Request for Comments 
(RFC), Ascend’s native RADIUS servers require this parameter. 


The RADIUS health check is performed using the configured real server port (rport). To 
configure RADIUS health checks, use the /cfg/slb/virt <#>/service menu. 


HTTPS/SSL Health Check 


The health sslh option on the Real Server Group Menu (/cfg/slb/group <#>) 
allows the switch to query the health of the SSL servers by sending an SSL client “Hello” 
packet and then verify the contents of the server’s “Hello” response. SSL health check is per¬ 
formed using the real server port configured, that is, the rport. 

The SSL enhanced health check behavior is summarized below: 

■ The switch sends a SSL “Hello” packet to the SSL server. 

■ If it is up and running, the SSL server responds with the “Server Hello” message. 

■ The switch verifies fields in the response and marks the service “Up” if the fields are OK. 

During the handshake, the user and server exchange security certificates, negotiate an encryp¬ 
tion and compression method, and establish a session ID for each session. 

Alteon (i ^Systems Chapter 10: Health Checking ■ 159 

050159A, May 2001 






Web OS 9.0 Application Guide 


WAP Health Checks 


The Wireless Application Protocol (WAP) describes a whole protocol stack which can carry 
Internet traffic to mobile devices. On the land-based part of the network, WAP Gateways con¬ 
vert HTML traffic to Wireless Markup Language (WML) traffic. 

WML traffic can be carried in encrypted or unencrypted form, similar to HTTP or HTTPS, 
respectively. The Wireless Session Protocol (WSP) is the unencrypted way of sending WML 
traffic. For encrypted WML traffic, WAP defines the Wireless Transport Layer Security 
(WTLS) protocol. 


WSP Content Health Checks 

WSP can be configured in two modes: connectionless and connection-oriented. Connection¬ 
less WSP runs on UDP/IP protocol, port 9200. Therefore, Alteon Web switches can be used to 
load balance the gateways in this mode of operation. 

Web OS 9.0 provides a content-based health check mechanism where customized WSP pack¬ 
ets can be sent to the gateways, and the switch can verify the expected response, in a manner 
similar to scriptable health checks. 

The content of the WSP/UDP packet that is sent to the gateway can be configured as a hexa¬ 
decimal string, which is encapsulated in a UDP packet and shipped to the server. Hence, this 
byte string should include all applicable WSP headers. 

The content that the switch expects to receive from the gateway is also specified in the form of 
hexadecimal byte string. The switch matches each byte of this string with the received content. 

If there is a mismatch of even a single byte on the received content, the gateway fails the health 
check. The user can also configure an offset for the received WSP packet: a byte index to the 
WSP response content from where the byte match can be performed. 

Configuring WSP Content Health Checks 

1. Select the WAP Health Check Menu. 


>> # /cfg/slb/adv/waphc 


2. Use the sndcnt command to enter the content to be sent to the WSP gateway. 


>> WAP Health Check# sndcnt 
Current Send content: 

Enter new Send content: 01 42 15 68 74 74 70 3a 2f 77 77 77 2e 6e 6f 
6b 61 6d 00 
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3. Enter the content that the switch expects to receive from the WSP gateway. 


» WAP Health Check# rcvcnt 
Current Receive content: 

Enter new Receive content: 01 04 60 Oe 03 94 


NOTE — A maximum of 255 bytes of input are allowed on the switch command line. You may 
remove spaces in between the numbers to save space on the command line. For example, type 

010203040506 instead of 01 02 03 04 05 06. 


4. Enter the WSP port. 


>> WAP Health Check# wspport 9200 


5. Set the offset value. 


» WAP Health Check# offset 0 


6. Because WAP gateways are UDP-based and operate on a UDP port, configure a service in 
the virtual server menu. 


>> # /cfg/slb/virt 1 

>> Virtual Server 1# service (Configure virtual sen’ice 1) 

Enter virtual port: 9200 (On the default WSP port) 

» Virtual Server 1 9200 Service# group 1 (Set the real server group number) 

» Virtual Server 1 9200 Service# udp ena (Enable UDP load balancing) 

» Virtual Server 1 9200 Service# apply (Apply the configuration) 


Enable WSP health checks for group 1. 


» # /cfg/slb/group 1 

(Select the Real Server Group 1 menu) 

>> Real server group 1# health wsp 

(Set the health check type) 

Apply and save the configuration. 


» Real server group 1# apply 
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WTLS Health Checks 

WTLS can be configured to use ports 9202 and 9203 in connection-less and connection-ori¬ 
ented modes respectively. 

The WTLS health check feature provides a WTLS Hello based health check for connection- 
oriented WTLS traffic on port 9203. The web switch sends a new WTLS Client Hello to the 
WAP gateway, and checks to see if it receives a valid WTLS Server Hello back from the WAP 
Gateway. 

Configuring WTLS Health Check 

1. Select the group with the WAP gateway. 


>> Main# /cfg/slb/group <groupnumber> 


2. Use the sndcnt command to enter the content to be sent to the WSP gateway. 


>> Real server group 1# health wtls 


3. Select a port number other than 9203, if you want to change the port number on which 
your gateway is listening to WTLS traffic. 


>> Main# /cfg/slb/adv/wap 

>> WAP Health Check Menu # wtlsprt 10203 


4. Apply and save your configuration. 


>> WSP Health Check# apply 
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Script-Based Health Checks 


Using this feature, you can configure the switch to send a series of health check requests to real 
servers or real server groups and monitor the responses. ASCII-based scripts can be used to 
verify application and content availability. 


NOTE — Only TCP services can be health checked, since UDP protocols are usually not ASCII 
based. 


The benefits of using script-based health checks are listed below: 

■ Ability to send multiple commands 

■ Check for any return string 

■ Test availability of different applications 

■ Test availability of multiple domains or Web sites 
Web OS supports the following capacity for a single switch: 

■ 1024 bytes per script 

■ 8 scripts per switch 

■ approximately 10 to 15 health check statements (HTTP get and expect strings) 

A simple command line interface controls the addition and deletion of ASCII commands to 
each script. New commands are added and removed from the end of the script. Commands 
exist to open a connection to a specific TCP port, send an ASCII request to the server, expect 
an ASCII string, and close a connection. The string configured with an expect command is 
searched for in each response packet. If it is not seen anywhere in any response packet before 
the real server health check interval expires, the server does not pass the expect step and fails 
the health check. A script can contain any number of these commands, up to the allowable 
number of characters that a script supports. 


NOTE — Health check scripts can only be set up via the command line interface, but once 
entered, can be assigned as the health-check method using SNMP or the Browser-Based Inter¬ 
face (BBI). 
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Script Format 

The general format for health-check scripts is shown below: 


open application_port (e.g., 80 for HTTP, 13 for Telnet, etc.) 

send requestl 

expect responsel 

send requestl 

expect responsel 

send request3 

expect response3 

close 


NOTE — If you are doing HTTP 1.1 pipelining, you need to individually open and close each 
response in the script. 


■ Each script should start with the command open port <protocol port number>. The 
next line can be either a send or expect. 

■ The first word is the method. This is usually get; however, HTTP supports several other 
commands, including put and head. The second word indicates the content desired, or 
request-URI, and the third word represents the version of the protocol used by the client. 

If you supplied HTTP/1.1 for the protocol version, you would also have to add in the fol¬ 
lowing line: Host: www. hostname . com 

Example: GET /index.html HTTP/1.1 (press Enter key) 

Host: www.hostname.com (press Enter key twice) 

This is known as a host header. It is important to include because most Web sites now 
require it for proper processing. Host headers were optional in HTTP/1.0 but are required 
when you use HTTP/1.1+. 

■ In order to tell the Web server you have finished entering header information, a blank line 
of input is needed after all headers. At this point, the URL will be processed and the 
results returned to you. 


NOTE — If you make an error, enter rem to remove the last typed script line entered. If you 
need to remove more than one line, enter rem for each line that needs to be removed. 


■ The switch provides the “\” prompt, which is one enter key stroke. When using the send 
command, note what happens when you type the send command with the command 
string. When you type send, press enter and allow the switch to format the command 
string (that is, \ versus \\). 
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Scripting Guidelines 

■ Use generic result codes that are standard and defined by the RFC, as applicable. This 
helps ensure that if the customer changes server software, the servers won’t start failing 
unexpectedly. 

■ Search only for the smallest and most concise piece of information possible. Each script 
cannot exceed IK in size, so use the space wisely. 

■ Avoid tasks that may take a long time to perform or the health check will fail. For exam¬ 
ple, avoid tasks that exceed the interval for load balancing. 

Script Configuration Examples 

Script Example 1: A Basic Health Check 

Configure the switch to check a series of Web pages (HTML or dynamic CGI scripts) before it 

declares a real server is available to receive requests. 


NOTE — If you are using the CLI to create a health check script, you must use quotes (“) to 
indicate the beginning and end of each command string. 


/cfg/slb/group x/health scriptl/content none 
/cfg/sib/adv/scriptl 

open 80 

send "GET /index.html HTTP/1.l\\r\\nHOST:www.hostname.cora\\r\\n\\r\\n" 
expect "HTTP/1.1 200" 

close 
open 80 

send "GET /script.cgi HTTP/1.l\\r\\nHOST:www.hostname.cora\\r\\n\\r\\n" 
expect "HTTP/1.1 200" 

close 
open 443 

close 


NOTE — When you are using the command line interface to enter the send string as an argu¬ 
ment to the send command, you must type two “\”s before an “n” or “r.” If you are instead 
prompted for the line, that is, the text string is entered after hitting <return>, then only one “\” 
is needed before the “n” or “r.” 
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Script Example 2: GSLB URL Health Check 

In earlier Web OS releases, each remote Global Server Load Balancing site’s virtual server IP 
address was required to be a real server of the local switch. Each switch sends a health check 
request to the other switch’s virtual servers that are configured on the local switch. The health 
check is successful if there is at least one real server on the remote switch that is up. If all real 
servers on the remote switch are down, the remote real server (a virtual server of a remote 
switch) will respond with an HTTP Redirect message to the health check. 

Using the scriptable health check feature, you can set up health check statements to check all 
the substrings involved in all the real servers. 

Site 1 with Virtual Server 1 and the following real servers: 

■ Real Server 1 and Real Server 2: “images” 

■ Real Server 3 and Real Server 4: “html” 

■ Real Server 5 and Real Server 6: “cgi” and “bin” 

■ Real Server 7 (which is Virtual Server 2): “any” 

Site 2 with Virtual Server 2 and the following real servers: 

■ Real Server 1 and Real Server 2: “images” 

■ Real Server 3 and Real Server 4: “html” 

■ Real Server 5 and Real Server 6: “cgi” and “bin” 

■ Real Server 7 (which is Virtual Server 2): “any” 

A sample script is shown below: 


/cfg/slb/group x/health script2/content none 
/cfg/slb/adv/script2 

open 80 

send "GET /images/default.asp HTTP/1.l\\r\\nHOST: 192.192.1.2\\r\\n\\r\\n" 
expect "HTTP/1.1 200" 

close 

open 80 

send "GET /install/default.html HTTP/1.l\\r\\nHOST: 192.192.1.2\\r\\n\\r\\n" 
expect "HTTP/1.1 200" 

close 

open 80 

send "GET /script.cgi HTTP/1.l\\r\\nHOST: www.myurl.com \\r\\n\\r\\n" 
expect "HTTP/1.1 200" 

close 
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Script-based health checking is intelligent in that it will only send the appropriate requests to 
the relevant servers. In the example above, the first GET statement will only be sent to Real 
Server 1 and Real Server 2. Going through the health-check statements serially will ensure that 
all content is available by at least one real server on the remote site. 

Configure the remote real server IP address (the virtual server IP address of the remote site) to 
accept “any” URL requests. The purpose of the first GET is to check if Real Server 1 or Real 
Server 2 is up—that is, to check if the remote site has at least one server for “images” content. 
Either Real Server 1 or Real Server 2 will respond to the first GET health check. 

If all the real server IP addresses are down. Real Server 7 (the virtual server IP address of the 
remote site) will respond with an HTTP Redirect (respond code 302) to the health check. Thus, 
the health check will fail as the expected response code is 200, ensuring that the HTTP Redi¬ 
rect messages will not cause a loop. 

Verifying Script-Based Health Checks 

If a script fails, the expect line in the script that is not succeeding is displayed under the 
/ info/sib/real <real server number> command: 


» # /info/slb/real 1 

1: 205.178.13.225, 00:00:00:00:00:00, vlan 1, port 0, health 4, FAILED 
real ports: 

script 2, DOWN, current 

send GET / HTTP/1.0\r\n\r\n 
expect HTTP/1.0 200 


The server is not responding to the get with the expect string. 

When the script succeeds in determining the health of a real server, the following information 
is displayed 


» # /info/slb/real 1 

1: 205.178.13.223, 00:00:5e:00:01:24, vlan 1, port 2, health 4, up 
real ports: 
script 2, up, current 
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Failure Types 


Service Failure 

If a certain number of connection requests for a particular service fail, the session switch 
places the service into the service failed state. While in this state, no new connection requests 
are sent to the server for this service; however, if graceful real server failure is enabled 
(/cfg/sib/adv/grace ena), state information about existing sessions is maintained and 
traffic associated with existing sessions continues to be sent to the server. Connection requests 
to, and traffic associated with, other load-balanced services continue to be processed by the 
server. 

Example: A real server is configured to support HTTP and FTP within two real server groups. 
If a session switch detects an HTTP service failure on the real server, it removes that real 
server group from the load-balancing algorithm for HTTP but keeps the real server in the mix 
for FTP. Removing only the failed service from load balancing allows users access to all 
healthy servers supporting a given service. 

When a service on a server is in the sendee failed state, the session switch sends Layer 4 con¬ 
nection requests for the failed service to the server. When the session switch has successfully 
established a connection to the failed service, the service is restored to the load-balancing algo¬ 
rithm. 

Server Failure 

If all load-balanced services supported on a server fail to respond to switch connection requests 
within the specified number of attempts, then the server is placed in the server failed state. 
While in this state, no new connection requests are sent to the server; however, if graceful real 
server failure is enabled (/cf g/slb/adv/grace ena), state information about existing 
sessions is maintained and traffic associated with existing sessions continues to be sent to the 
server. 


NOTE — All load-balanced services on a server must fail before the switch places the server in 
the server failed state. 


The server is brought back into service as soon as the first service is proven to be healthy. 
Additional services are brought online as they are subsequently proven to be healthy. 
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High Availability 


Alteon Web switches support high-availability network topologies through an enhanced imple¬ 
mentation of the Virtual Router Redundancy Protocol (VRRP). 

In a high-availability network topology, no device can create a single point-of-failure for the 
network or force a single point-of-failure to any other part of the network. This means that 
your network will remain in service despite the failure of any single device. To achieve this 
usually requires redundancy for all vital network components. 

The following topics are discussed in this chapter: 

■ “VRRP Overview” on page 170. This section discusses VRRP operation and Alteon Web¬ 
Systems’ redundancy configurations. 

■ “Failover Methods” on page 174. This section describes the three modes of high availabil¬ 
ity. 

■ “Web OS Extensions to VRRP” on page 180. This section describes VRRP enhancements 
implemented in Web OS. 

■ “High Availability Configurations” on page 183. This section discusses a few of the more 
useful and easily deployed redundant configurations. 

□ Active-Standby Virtual Server Router Configuration 

□ Active-Active VIR and VSR Configuration 

□ Active/Active Server Load Balancing Configuration 

□ VRRP-Based Hot-Standby Configuration 

■ “Virtual Router Deployment Considerations” on page 197. This section describes issues to 
consider when deploying virtual routers. 
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VRRP Overview 


To understand the operation of Alteon WebSystems’ redundancy configurations, this section 
describes VRRP operation and the Alteon-specific extensions to VRRP. 

VRRP enables redundant router configurations within a LAN, providing alternate router paths 
for a host to eliminate single points-of-failure within a network. Each participating VRRP- 
capable routing device is configured with the same virtual router IP address and ID number. 
One of the virtual routers is elected as the master, based on a number of priority criteria, and 
assumes control of the shared virtual router IP address. If the master fails, one of the backup 
virtual routers will take control of the virtual router IP address and actively process traffic 
addressed to it. 

Because the router associated with a given alternate path supported by VRRP uses the same IP 
address and MAC address as the routers for other paths, the host’s gateway information does 
not change, no matter what path is used. A VRRP-based redundancy schema reduces adminis¬ 
trative overhead because hosts need not be configured with multiple default gateways. 

VRRP Components 

Each physical router running VRRP is known as a VRRP router. 

Virtual Interface Router 

Two or more VRRP routers can be configured to form a virtual interface router (VIR). (RFC 
2338 calls this entity a virtual router.) The term virtual interface router will be used to distin¬ 
guish this type of entity from a virtual server router (VSR), as described in “Web OS Exten¬ 
sions to VRRP” on page 180. When the term virtual router is used herein, the concept applies 
to both virtual interface routers and virtual server routers. Each VRRP router may participate 
in one or more virtual interface routers. 

A virtual interface router acts as a default or next hop gateway for hosts on a LAN. Each vir¬ 
tual interface router consists of a user-configured virtual router identifier (VRID) and an IP 
address. 

Virtual Router MAC Address 

The VRID is used to build the virtual router MAC Address. The five highest-order octets of the 
virtual router MAC Address are the standard MAC prefix (00-00-5E-00-01) defined in RFC 
2338. The VRID is used to form the lowest-order octet. 
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Owners and Renters 

Only one of the VRRP routers in a virtual interface router may be configured as the IP address 
owner. This router has the virtual interface router’s IP address as its real interface address. This 
router responds to packets addressed to the virtual interface router’s IP address for ICMP 
pings, TCP connections, and so on. 

There is no requirement for any VRRP router to be the IP address owner. Most VRRP installa¬ 
tions choose not to implement an IP address owner. For the purposes of this chapter, VRRP 
routers that are not the IP address owner are called renters. 

Master and Backup Virtual Router 

Within each virtual router, one VRRP router is selected to be the virtual router master. See 
“Selecting the Master VRRP Router” on page 172 for an explanation of the selection process. 


NOTE — If the IP address owner is available, it will always become the virtual router master. 


The virtual router master forwards packets sent to the virtual interface router. It also responds to 
Address Resolution Protocol (ARP) requests sent to the virtual interface router’s IP address. 
Finally, the virtual router master sends out periodic advertisements to let other VRRP routers 
know it is alive and its priority. 

Within a virtual router, the VRRP routers not selected to be the master are known as virtual 
router backups. Should the virtual router master fail, one of the virtual router backups becomes 
the master and assumes its responsibilities. 

The Alteon Web switches in Figure 11-1 have been configured as VRRP routers. Together, 
they form a virtual interface router (VIR). 
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Figure 11-1 Example 1: VRRP Router 
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The switch on the left in Figure 11-1 has its real interface configured with the IP address of the 
virtual interface router and is, therefore, the IP address owner. It also becomes the virtual 
router master. The switch on the right is a virtual router backup. Its real interface is configured 
with an IP address that is on the same subnet as the virtual interface router but is not the IP 
address of the virtual interface router. 

The virtual interface router has been assigned a VRID = 1. Therefore, both of the VRRP rout¬ 
ers have a MAC address = 00-00-5E-00-01-01. 

VRRP Operation 

The host shown in Figure 11-1 is configured with the virtual interface router’s IP address as its 
default gateway. The master forwards packets destined to remote subnets and responds to ARP 
requests. In this example, the master is also the virtual interface router’s IP address owner— 
therefore it also responds to ICMP ping requests and IP datagrams destined for the virtual 
interface router's IP address. The backup does not forward any traffic on behalf of the virtual 
interface router nor does it respond to ARP requests. 

If the owner is not available, the backup becomes the master and takes over responsibility for 
packet forwarding and responding to ARP requests. However, because this switch is not the 
owner, it does not have a real interface configured with the virtual interface router's IP address. 

Selecting the Master VRRP Router 

Each VRRP router that is not an owner is configured with a priority between 1-254. According 
to the VRRP standard, an owner has a priority of 255. A bidding process determines which 
VRRP router is or becomes the master—the VRRP router with the highest priority. Owners 
have a higher priority than the range permitted for non-owners. If there is an IP address owner, 
it is always the master for the virtual interface router, as long as it is available. 

The master periodically sends advertisements to an IP multicast address. As long as the back¬ 
ups receive these advertisements, they remain in the backup state. If a backup does not receive 
an advertisement for three advertisement intervals, it initiates a bidding process to determine 
which VRRP router has the highest priority and takes over as master. 

If, at any time, a backup determines that it has higher priority than the current master does, it 
can preempt the master and become the master itself, unless configured not to do so. In pre¬ 
emption, the backup assumes the role of master and begins to send its own advertisements. The 
current master sees that the backup has higher priority and will stop functioning as the master. 
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A backup router can stop receiving advertisements for one of two reasons—the master can be 
down, or all communications links between the master and the backup can be down. If the 
master has failed, it is clearly desirable for the backup (or one of the backups, if there is more 
than one) to become the master. 


Note - If the master is healthy but communication between the master and the backup has 
failed, there will then be two masters within the virtual router. To prevent this from happening, 
configure redundant links to be used between the switches that form a virtual router. 


Active-Standby Failover 


The previous text described the use of a group of VRRP routers to form a single virtual inter¬ 
face router. It implements a traditional hot-standby configuration in which the backup router 
only functions when the active router has failed. VRRP can also be used to implement active- 
standby configurations. In an active-standby configuration, both switches support active traf¬ 
fic, but are configured so that they do not simultaneously support the same service. 

In the example shown in Figure 11-2, the switch on the left is the master for the virtual inter¬ 
face router with VRID = 1, and its backup for the virtual interface router with VRID = 2. The 
switch on the right is master for the virtual interface router with VRID = 2 and backup for the 
virtual interface router with VRID = 1. In this manner, both routers can actively forward traffic 
at the same time but not for the same interface. 
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Figure 11-2 Example 2: VRRP Router 
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Failover Methods 


With service availability becoming a major concern on the Internet, service providers are 
increasingly deploying Internet traffic control devices, such as Web switches, in redundant 
configurations. Traditionally, these configurations have been hot-standby configurations, 
where one switch is active and the other is in a standby mode. A non-VRRP hot-standby con¬ 
figuration is shown in the figure below: 


Intranet Clients 


Primary Web Switch Active Links Intranet Servers 



IP: 200.200.200.101 Backup Links NFS Server 


Figure 11-3 A Non-VRRP, Hot-Standby Configuration 

While hot-standby configurations increase site availability by removing single points-of-fail- 
ure, service providers increasingly view them as an inefficient use of network resources 
because one functional Web switch sits by idly until a failure calls it into action. Service pro¬ 
viders now demand that vendors’ equipment support redundant configurations where all 
devices can process traffic when they are healthy, increasing site throughput and decreasing 
user response times when no device has failed. 

Alteon WebSystems high availability configurations are based on VRRP. The Web OS imple¬ 
mentation of VRRP includes proprietary extensions to accomodate Layer 4 though Layer 7 
Web switching features. 

The Web OS implementation of VRRP supports three modes of high availability: 

■ Active-Standby 

■ Active-Active 

■ Hot-Standby 

The first mode, active-standby, is based on standard VRRP, as defined in RFC 2338. The sec¬ 
ond and third modes, active-active and hot-standby, are based on proprietary Alteon Web¬ 
Systems extensions to VRRP. Each mode is described in detail in the following sections. 
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Active-Standby Redundancy 


In an active-standby configuration, shown in Figure 11-4, two Web switches are used. Both 
switches support active traffic but are configured so that they do not simultaneously support 
the same service. Each switch is active for its own set of services, such as IP routing interfaces 
or load-balancing virtual server IP addresses, and acts as a standby for other services on the 
other switch. If either switch fails, the remaining switch takes over processing for all services. 
The backup switch may forward Layer 2 and Layer 3 traffic, as appropriate. 


NOTE — In an active-standby configuration, the same service cannot be active simultaneously 
on both switches. 


Internet 


VIP 


Standby VIP si 
VIP 205.178,13. 


Active 


Active 



Standby VIP <H 
VIP 205.178.13.240 


I I 9 . 9 



Active VIP -q 
VIP 205.178.13.240 


Standby VIP -"3 
VIP 20S.11S.13.UI1 


Figure 11-4 Active-Standby Redundancy 
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Active-Active Redundancy 

In an active-active configuration, two Web switches provide redundancy for each other, with 
both active at the same time for the same services. 

Alteon WebSystems has extended VRRP to include virtual servers, allowing full active/active 
redundancy between its Layer 4 switches. In an active-active configuration, shown in Figure 
11-5, both switches can process traffic for the same service at the same time; both switches can 
be active simultaneously for a given IP routing interface or load-balancing virtual server (VIP). 


Internet 

Active VIP si 
VIP - 205.1 "8.13.226 


Active VIP s2 
VIP - 205.178.13.240 


Active VIP s3 
VIP 205.178.13.110 


Figure 11-5 Active-Active Redundancy 

In the example above, one switch is still the master router. However, traffic going through the 
backup router (associated with the same virtual router on the switch) that is addressed to the 
master router will be intercepted and processed by the backup router. 

Hot-Standby Redundancy 

In a hot-standby configuration. Spanning Tree Protocol (STP) is not needed to eliminate bridge 
loops. This speeds up failover when a switch fails. The standby switch blocks all ports configured 
as standby ports, whereas the master switch enables these same ports. Consequently, on a given 
switch, all virtual routers are either master or backup; they cannot change state individually. 

To provide as much flexibility as possible, the old hot-standby approach has been modified to 
eliminate the problems previously associated with it and is now based on VRRP. In a hot-standby 
configuration, two or more switches provide redundancy for each other. One switch is elected 
master and actively processes Layer 4 traffic. The other switches (the backups) assume the master 
role should the master fail. The backups may forward Layer 2 and Layer 3 traffic as appropriate. 
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There are three components to the VRRP-based, hot-standby model: the virtual router group, 
additional Layer 4 port states, and configuration synchronization options. The hot-standby 
model is shown in Figure 11-6. 


Internet 



Active VIP »3 
VIP = 205.178.13.1 


Active 


Active VIP «2 
\1P 205.178.13.240 


Active VIPal 
VIP = 205.178.13.226 


.SlHndhv VIP "I 
VIP = 205.178.13.226 


Stmidbv WP --2 
VIP - 205.1 "8.13.240 


■Standby VIP : -3 
VIP - 205.178.13.1 H» 


Figure 11-6 Hot-Standby Redundancy 


Virtual Router Group 

The virtual router group ties all of the virtual routers together as a single entity and is central to 
the hot-standby configuration. All virtual routers on a given switch must all be either master or 
backup. They cannot failover individually, only as a group. Once hot-standby is globally 
enabled, the virtual router group must be enabled. The virtual router group aggregates all of the 
virtual routers as a single entity. 

If the virtual router group is master on one switch, it means the switch is master; otherwise, the 
switch is backup. However, Layer 4 processing is still enabled. If a virtual server is not a vir¬ 
tual router, the backup switch can still process traffic addressed to that virtual server IP 
address. Filtering is also still functional. Only traffic addressed to virtual server routers is not 
processed. 

VRRP actually contains support for virtual router groups. Each advertisement is not limited to 
a single virtual router IP address and can include up to 256 addresses. This means that all vir¬ 
tual routers are advertised in the same packet, conserving processing and buffering resources. 
However, the advertisements are also used to help bridges learn the virtual router MAC 
address. Since all of the virtual routers can have different virtual router identifiers (VRIDs), 
you must rotate the MAC source address of the advertisement to ensure that the bridges learn 
all of the virtual router MAC addresses. 
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Hot-Standby and Inter-Switch Port States 

The second part of the solution involves introducing two additional Layer 4 port states, hot- 
standby and inter-switch: 

■ Links that attach to the standby switch must be configured as hot standby using 

/cfg/slb/port x/hotstan. 

■ Links that are used by VRRP to deliver updates are configured as intersw, or inter¬ 
switch links (not to be confused with Cisco’s ISL). The command to configure one or 
more ports as interswitch links is /cfg/slb/port <port number >/ intersw. 


NOTE — A port cannot be configured to support both hot-standby and interswitch link. 


The hot-standby switch listens to the master’s VRRP updates. After an interval period has 
expired without receiving a update, the backup switch will take over. The forwarding states of 
hot-standby ports are controlled much like the forwarding states of the old hot-standby 
approach. Enabling hot-standby on a switch port allows the hot-standby algorithm to control 
the forwarding state of the port. If a switch is master, the forwarding states of the hot-standby 
ports are enabled. If a switch is backup, the hot-standby ports are blocked from forwarding or 
receiving traffic. 

When the hotstan option (/cfg/slb/port x/hotstan) is enabled and all hot-standby 
ports have link, the virtual router group's priority is automatically incremented by the “track 
other virtual routers” value. This action allows the switches to failover when a hot-standby port 
loses link. Other enabled tracking features only have affect when all hot-standby ports on a 
switch have link. The default virtual routers tracking value is 2 seconds. Keep in mind that this 
is an automatic process that cannot be turned off. 


NOTE — The VRRP hot-standby approach does not support single-link failover. If one hot- 
standby port loses link, the entire switch must become master to eliminate loss of connectivity. 


The forwarding states of non-hot-standby ports are not controlled via the hot-standby algo¬ 
rithm, allowing the additional ports on the switches to provide added port density. The client 
ports on both switches should be able to process or forward traffic to the master switch. 

The inter-switch port state is only a place holder. Its presence forces the user to configure a 
inter-switch link when hot-standby is globally enabled and prohibits the inter-switch link from 
also being a hot-standby link for VRRP advertisements. These advertisements must be able to 
reach the backup switch. 
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Synchronizing Configurations 

The final piece in configuring a high-availability solution includes the addition of synchroniza¬ 
tion options to simplify the manual configuration. Configuration options have been added to 
refine what is synchronized, to whom, and to disable synchronizing certain configurations. 
These options include proxy IP addresses. Layer 4 port configuration, filter configuration, and 
virtual router priorities. 

Also, a peer menu (cf g/sib/sync/peer) has been added to allow the user to configure 
the IP addresses of the switches that should be synchronized. This provides added synchroni¬ 
zation validation but does not require the users to enter the IP address of the redundant switch 
for each synchronization. 


NOTE — When using both VRRP and GSLB, you must change the /cfg/sys/wport 
(Browser-Based Interface port) value of the target switch (the switch that is being synchro¬ 
nized to) to a port other than port 80 before VRRP synchronization begins. 


For more information on synchronizing configurations between two switches, see “Synchro¬ 
nizing Configurations” on page 201. 
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Web OS Extensions to VRRP 


This section describes the following VRRP enhancements that are implemented in Web OS: 

■ Virtual Server Routers 

■ Sharing/Active-Active Failover 

■ Tracking VRRP Router Priority 

Virtual Server Routers 

Web OS supports virtual server routers, which extend the benefits of VRRP to virtual server IP 
addresses that are used to perform SLB. 

Virtual server routers operate for virtual server IP addresses in much the same manner as Vir¬ 
tual Interface Routers operate for IP interfaces. A master is negotiated via a bidding process, 
during which information about each VRRP router’s priority is exchanged. Only the master can 
process packets that are destined for the virtual server IP address and respond to ARP requests. 

One difference between virtual server routers and virtual interface routers is that a virtual 
server router cannot be an IP address owner. All virtual server routers are renters. 

All virtual routers, whether virtual server routers or virtual interface routers, operate indepen¬ 
dently of one another; that is, their priority assignments, advertisements, and master negotia¬ 
tions are separate. For example, when you configure a VRRP router’s priority in a virtual 
server router, you are not affecting that VRRP router’s priority in any virtual interface router or 
any other virtual server router of which it is a part. However, because of the requirement that 
MAC addresses be unique on a LAN, VRIDs must be unique among all virtual routers, 
whether virtual interface routers or virtual server routers. 
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Sharing/Active-Active Failover 

Web OS supports sharing of interfaces at both Layer 3 and Layer 4, as shown in Figure 11-7. 
With sharing, an IP interface or a VIP address can be active simultaneously on multiple 
switches, enabling active-active operation. 


Internet 



Figure 11-7 Active-Active High Availability 


When sharing is used, incoming packets are processed by the switch on which they enter the 
virtual router. The ingress switch is determined by external factors, such as routing and Span¬ 
ning Tree configuration. 


NOTE — Sharing cannot be used in configurations where incoming packets have more than one 
entry point into the virtual router—for example, where a hub is used to connect the switches. 


When sharing is enabled, the master election process still occurs. Although the process does 
not affect which switch processes packets that must be routed or that are destined for the vir¬ 
tual server IP address, it does determine which switch sends advertisements and responds to 
ARP requests sent to the virtual router’s IP address. 

Alteon WebSystems strongly recommends that sharing, rather than active-standby configura¬ 
tions, be used whenever possible. Sharing offers both better performance and fewer service 
interruptions in the face of fault conditions than active-standby configurations. 
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Tracking VRRP Router Priority 

Web OS supports a tracking function that dynamically modifies the priority of a VRRP router, 
based on its current state. The objective of tracking is to have, whenever possible, the master 
bidding processes for various virtual routers in a LAN converge on the same switch. Tracking 
ensures that the selected switch is the one that offers optimal network performance. For track¬ 
ing to have any effect on virtual router operation, preemption must be enabled. 


NOTE — Tracking only affects hot standby and active-standby configurations. It does not have 
any effect on active-active sharing configurations. 

Web OS can track the attributes listed in Table 11-1: 

Table 11-1 VRRP Tracking Parameters 

Parameter 

Description 

Number of virtual routers in master 

mode on the switch 

/cfg/vrrp/track/vrs 

Useful for ensuring that traffic for any particular cli¬ 
ent/server pair is handled by the same switch, 
increasing routing and load-balancing efficiency. 

This parameter influences the VRRP router’s prior¬ 
ity in both virtual interface routers and virtual server 
routers. 

Number of IP interfaces active on the 

switch 

/cfg/vrrp/track/ifs 

Helps elect the virtual routers with the most avail¬ 
able routes as the master. (An IP interface is consid¬ 
ered active when there is at least one active port on 
the same VLAN.) This parameter influences the 

VRRP router’s priority in both virtual interface rout¬ 
ers and virtual server routers. 

Number of active ports on the same 
VLAN 

/cfg/vrrp/track/ports 

Helps elect the virtual routers with the most avail¬ 
able ports as the master. This parameter influences 
the VRRP router’s priority in both virtual interface 
routers and virtual server routers. 

Number of physical switch ports that 
have active Layer 4 processing on the 
switch 

/cfg/vrrp/track/14pts 

Helps elect the main Layer 4 switch as the master. 

This parameter influences the VRRP router’s prior¬ 
ity in both virtual interface routers and virtual server 
routers. 
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Table 11-1 VRRP Tracking Parameters 


Parameter 

Description 

Number of healthy real servers behind 
the virtual server IP address that is the 
same as the IP address of the virtual 

server router on the switch 

/cfg/vrrp/track/reals 

Helps elect the switch with the largest server pool as 
the master, increasing Layer 4 efficiency. This 
parameter influences the VRRP router's priority in 
virtual server routers only. 

In networks where the Hot Standby 
Router Protocol (HSRP) is used for 
establishing router failover, the num¬ 
ber of Layer 4 client-only ports that 
receive HSRP advertisements 
/cf g/ vrrp/track/hsrp 

Helps elect the switch closest to the master HSRP 
router as the master, optimizing routing efficiency. 
This parameter influences the VRRP router's prior¬ 
ity in both virtual interface routers and virtual server 
routers. 


Each tracked parameter has a user-configurable weight associated with it. As the count associ¬ 
ated with each tracked item increases (or decreases), so does the VRRP router’s priority, sub¬ 
ject to the weighting associated with each tracked item. If the priority level of a backup is 
greater than that of the current master, then the backup can assume the role of the master. 

See “Configuring the Switch for Tracking” on page 199 for an example on how to configure 
the switch for tracking VRRP priority. 

High Availability Configurations 


Alteon Web switches offer flexibility in implementing redundant configurations. This section 
discusses a few of the more useful and easily deployed configurations: 

■ “Active-Standby Virtual Server Router Configuration” on page 184 

■ “Active-Active VIR and VSR Configuration” on page 186 

■ “Active/Active Server Load Balancing Configuration” on page 188 

■ “VRRP-Based Hot-Standby Configuration” on page 195 
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Active-Standby Virtual Server Router Configuration 

Figure 11-8 shows an example configuration where two Alteon Web switches are used as 
VRRP routers in an active-standby configuration, implementing a virtual server router. Active- 
standby redundancy should be used in configurations that cannot support sharing, that is, con¬ 
figurations where incoming packets will be seen by more than one switch, such as instances 
where a hub is used to connect the switches. In this configuration, when both switches are 
healthy, only the master responds to packets sent to the virtual server IP address. 


Internet 



ripi = 205 .rra.moi s<rvw 2 3 in i*i = 205.i78.mo4 

RIP 2- 205.178.Lt.105 RIPI = 205.178.15.102 RIPI = 205.178.15.103 RIP 2= 205 178.LUM 

hip 2- 20s.iT8.mo6 rip 2 205 .i 78 .moT 

Figure 11-8 Active-Standby High-Availability Configuration 

Although this example shows only two switches, there is no limit on the number of switches 
used in a redundant configuration. It is possible to implement an active-standby configuration 
across all the VRRP-capable switches in a LAN. 

Each VRRP-capable switch in an active-standby configuration is autonomous. Switches in a 
virtual router need not be identically configured. 

To implement the active-standby example, perform the following switch configuration: 

1. Configure the appropriate Layer 2 and Layer 3 parameters on both switches. 

This includes any required VLANs, IP interfaces, default gateways, and so on. If IP interfaces 
are configured, none should use the virtual server IP address described in Step 4. 

2. Define all filters required for your network configuration. 

Filters may be configured on one switch and synchronized with settings on the other switch 
(see Step 5 below). 
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3. Configure all required SLB parameters on the left-hand switches. 

For the purposes of this example, assume that the switch on the left in Figure 11-8 is config¬ 
ured in this step. Required Layer 4 parameters include a VIP = 205.178.13.226 and one real 
server group with four real servers, RIP = 205.178.13.101, RIP = 205.178.13.102, RIP = 
205.178.13.103, and RIP = 205.178.13.104. 

4. Configure the VRRP parameters on the left-hand switch. 

This configuration includes VRID = 2, VIP = 205.178.13.226 and the priority. Enable tracking 
and set the parameters appropriately (refer to “Configuring the Switch for Tracking” on page 
199). Make sure to disable sharing. 

5. Synchronize the SLB and VRRP configurations by synchronizing the configuration from 
the switch on the left to the one on the right. 

Use the /oper/sib/synch command (see “Synchronizing Configurations” on page 201). 

6. Change the real servers in the right-hand switch’s configuration to RIP = 205.178.13.105, 
RIP = 205.178.13.106, RIP =205.178.13.107, and RIP = 205.178.13.108. 

Adjust the right-hand switch’s priority appropriately (see “Configuring the Switch for Tracking” 
on page 199). 

In this example, with the left-hand switch as the master, if a link between the left-hand switch 
and a server fails, the server will fail health checks and be taken out of the load-balancing algo¬ 
rithm. If tracking is enabled and is configured to take into account the number of healthy real 
servers for the Virtual Router's VIP address, the left-hand switch’s priority will be reduced. If it 
is reduced to a value lower than the right-hand switch’s priority, the right-hand switch will 
assume the role of master. 


NOTE — In this case, all active connections serviced by the left-hand switch’s virtual server IP 
address are severed. 


If the link between the left-hand (master) switch and its Internet router fails, the protocol used 
to distribute traffic between the routers, for example. Open Shortest Path First (OSPF), will 
reroute traffic to the other router. The right-hand (backup) switch will act as a Layer 2/3 switch 
and forward all traffic destined to the virtual server IP address to the left-hand switch. 

If the entire left-hand (master) switch fails, the protocol used to distribute traffic between the 
routers, such as OSPF, will reroute traffic to the right-hand router. The right-hand (backup) 
switch detects that the master has failed because it will stop receiving advertisements. The 
backup then assumes the master's responsibility of responding to ARP requests and issuing 
advertisements. 
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Active-Active VIR and VSR Configuration 


Figure 11-9 two Alteon Web switches are used as VRRP routers in an active-active configura¬ 
tion implementing a virtual server router. As noted earlier, this is the preferred redundant con¬ 
figuration. 


Internet 



Sava 4 

RIP - 205.178.13.104 


Figure 11-9 Active-Active High-Availability Configuration 

Although this example shows only two switches, there is no limit on the number of switches 
used in a high availability configuration. It is possible to implement an active-active configura¬ 
tion and perform load sharing between all of the VRRP-capable switches in a LAN. 

In this configuration, when both switches are healthy, the load balanced packets are sent to the 
virtual server IP address, resulting in higher capacity and performance than when the switches 
are used in an active-standby configuration. 

The switch on which a frame enters the virtual server router is the one that processes that 
frame. The ingress switch is determined by external factors, such as routing and STP settings. 


NOTE — Each VRRP-capable switch is autonomous. There is no requirement that the switches 
in a virtual router be identically configured. Different switch models with different numbers of 
ports and different enabled services may be used in a virtual router. 


To implement this example, configure the switches as follows: 

1. Configure the appropriate Layer 2 and Layer 3 parameters on both switches. 

This configuration includes any required VLANs, IP interfaces, default gateways, and so on. If 
IP interfaces are configured, none of them should use the VIP address described in Step 4. 
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2. Define all filters required for your network configuration. 

Filters may be configured on one switch and synchronized with the settings on the other switch 
(see Step 5, below). 

3. Configure all required SLB parameters on one of the switches. 

For the purposes of this example, assume that the switch on the left (see Figure 11-9 on page 
186) is configured in this step. Required Layer4 parameters include a VIP = 205.178.13.226 
and one real server group with two real servers, RIP = 205.178.13.101 and RIP = 
205.178.13.102. 

RIP = 205.178.13.103 should be configured as a backup server to RIP = 205.178.13.101. 

RIP = 205.178.13.104 should be configured as a backup server to RIP = 205.178.13.102. 


NOTE — In this configuration, each server’s backup is attached to the other switch. This ensures 
that operation will continue if all of the servers attached to a switch fail. 

4. Configure the VRRP parameters on the switch. 

Configure VRID = 2, VIP address = 205.178.13.226, and priority. Be sure to enable sharing. 

5. Synchronize the SLB and VRRP configurations by pushing the configuration from the 
switch on the left to the one on the right. 

Use the / oper/sib/sync command. 

6. Reverse the roles of the real servers and their backups in the right switch’s configuration. 

Configure RIP = 205.178.13.103 and RIP= 205.178.13.104 as the real servers 
Configure RIP = 205.178.13.101 and RIP = 205.178.13.102 as their backups, respectively. 

In this configuration, if a link between a switch and a server fails, the server will fail health 
checks and its backup (attached to the other switch) will be brought online. If a link between a 
switch and its Internet router fails, the protocol used to distribute traffic between the routers 
(for example, OSPF) will reroute traffic to the other router. Since all traffic now enters the vir¬ 
tual server router on one switch, that switch will process all incoming connections. 

If an entire master switch fails, the backup will detect this failure because it will stop receiving 
advertisements. The backup will assume the master’s responsibility of responding to ARP 
requests and issuing advertisements. 

Be cautious before setting the maximum connections (maxconn) metric in this configuration. 
The maxcon number is not shared between switches. Therefore, if a server is used for normal 
operation by one switch and is activated simultaneously as a backup by the other switch, the 
total number of possible connections to that server will be the sum of the maximum connection 
limits defined for it on both switches. 
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Active/Active Server Load Balancing Configuration 

In this example, you set up four virtual servers each load balancing two servers providing one 
service (for example, HTTP) per virtual server. 

You are load balancing HTTP, HTTPS, POP3, SMTP, and FTP. Each protocol is load balanced 
via a different virtual server. You could load balance all of these services on one VIP, but in this 
example, four distinct virtual servers are used to illustrate the benefits of active/active failover. 
Set up one switch, dump out the configuration script (also called a text dump), edit it, and 
dump the edited configuration into the peer switch. 


NOTE — Configuring the switch for active-active failover should take no longer than 15 min¬ 
utes to complete. You can use either the Web OS Browser-Based Interface (BBI) or the Com¬ 
mand Line Interface (CLI) for configuration. 


Task 1: Background Configuration 

1. Define the IP interfaces. 

The switch will need an IP interface for each subnet to which it will be connected so it can 
communicate with devices attached to it. Each interface will need to be placed in the appropri¬ 
ate VLAN. In our example. Interfaces 1, 2, 3, and 4 will be in VLAN 2 and Interface 5 will be 
in VLAN 1. 


NOTE — On Alteon Web switches, you may configure more than one subnet per VLAN. 


To configure the IP interfaces for this example, enter the following commands from the CLI: 


>> Main# /cfg/ip/if 1 

>> IP Interface 1 # addr 10.10.10.10 

>> IP Interface 1 # vlan 2 
>> IP Interface 1 # ena 


(Select IP interface 1) 

(Assign IP address for the interface) 
(Assign VLAN for the interface) 
(Enable IP interface 1) 


Repeat the commands for each interface listed below: 

■ IL 2 20.10.10.10 

■ IL 3 30.10.10.10 

■ IL 4 40.10.10.10 

■ IL 5 200.1.1.10 
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2. Define the VLANs. 

In this configuration, set up two VLANs: One for the outside world (the ports connected to the 
upstream switches, toward the routers) and one for the inside (the ports connected to the down¬ 
stream switches, toward the servers). 


» Main# /cfg/vlan <VLANnumber> 

» vlan 1 # add <portnumber> 

» vlan 1 # ena 

(Select VLAN 1) 

(Add a port to the VLAN membership) 
(Enable VLAN 1) 

Repeat this command for the second VLAN. 


■ VLAN 1 - IF 5—physical ports connected to upstream switches. 

■ VLAN 2 - IFs 1,2,3 A —physical ports connected to downstream switches. 

Disable Spanning Tree. 


>> Main# /cfg/stp 1 
>> Main# /cfg/stp/off 
>> Main# /cfg/stp/apply 

(Select the STP Group number) 

(Disable STP) 

(Make your changes active) 

Enable IP forwarding. 


IP forwarding is enabled by default. Make sure IP forwarding is enabled if the virtual server IP 
addresses and real server IP addresses are on different subnets, or if the switch is connected to 
different subnets and those subnets need to communicate through the switch. If you are in 
doubt as to whether or not to enable IP forwarding, enable it. In this example, the virtual server 
IP addresses and real server IP addresses are on different subnets, so enable this feature using 
the following command: 

» Main# /cfg/ip/frwd/on 

(Enable IP forwarding) 


Task 2: SLB Configuration 

1. Define the Real Servers. 

The real server IP addresses are defined and put into four groups, depending on the service 
they are running. Notice that RIPs 7 and 8 are on routable subnets in order to support passive 
FTP. For each real server, you must assign a real server number, specify its actual IP address, 
and enable the real server. 
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For example: 


>> 

Main# /cfg/slb/real 1 

(Server A is real server 1) 

>> 

Real server 1 # rip 10.10.10.5/24 

(Assign Server A IP address) 

>> 

Real server 1 # ena 

(Enable real server 1) 


Repeat this sequence of commands for the following real servers: 

■ RIP 2 10.10.10.6/24 

■ RIP 3 20.10.10.5/24 

■ RIP 4 20.10.10.6/24 

■ RIP 5 30.10.10.5/24 

■ RIP 6 30.10.10.6/24 

■ RIP 7 200.1.1.5/24 

■ RIP 8 200.1.1.6/24 

2. Define the real server groups, adding the appropriate real servers. 

This combines the three real servers into one service group: 


» 

Real 

server 

8 # /cfg/slb/group 1 

(Select real sen’er group 1) 

» 

Real 

server 

group 1# add 1 

(Add real server 1 to group 1) 

» 

Real 

server 

group 1# add 2 

(Add real server 2 to group 1) 


Repeat this sequence of commands for the following real server groups: 

■ Group 2—Add RIP 3 and 4 

■ Group 3—Add RIP 5 and 6 

■ Group 4—Add RIP 7 and 8 

3. Define the virtual servers. 

After defining the virtual server IP addresses and associating them with a real server group 
number, you must tell the switch which IP ports/services/sockets you want to load balance on 
each VIP. You can specify the service by either the port number, service name, or socket num¬ 
ber. 


» 

Real server group 

4 # /cfg/slb/virt 1 

(Select virtual server 1) 

» 

Virtual 

server 

i 

# vip 200.200.200.100 

(Assign a virtual seryer IP address) 

» 

Virtual 

Server 

i 

# service 80 

(Assign HTTP service port 80) 

» 

Virtual 

server 

i 

http Service # group 

1 (Associate virtual port to real group) 

» 

Virtual 

server 

i 

# ena 

(Enable the virtual server) 
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Repeat this sequence of commands for the following virtual servers: 

■ VIP 2 200.200.200.101 will load balance HTTPS (Port 443) to Group 2 

■ VIP 3 200.200.200.102 will load balance POP/SMTP (Ports 110/25) to Group 3 

■ VIP 4 200.200.200.104 will load balance FTP (Ports 20/21) to Group 4 

4. Define the client and server port states. 

Defining a client port state tells that port to watch for any frames destined for the VIP and to 
load balance them if they are destined for a load-balanced service. Defining a server port state 
tells the port to the do the remapping (NAT) of the real server IP address back to the virtual 
server IP address. Note the following: 

■ The ports connected to the upstream switches (the ones connected to the routers) will need 
to be in the client port state. 

■ The ports connected to the downstream switches (the ones providing fan out for the serv¬ 
ers) will need to be in the server port state. 

Configure the ports, using the following sequence of commands: 


>> 

Virtual 

server 4# /cfg/slb/port 1 

(Select physical switch port 1) 

>> 

SLB 

port 

A1 

# client ena 

(Enable client processing on port 1) 

>> 

SLB 

port 

A1 

# ../port 2 

(Select physical switch port 2) 

>> 

SLB 

port 

A2 

# server ena 

(Enable server processing on port 2) 


Task 3: Virtual Router Redundancy Configuration 

1. Configure virtual routers 2,4, 6, and 8. 

These virtual routers will have the same IP addresses as the virtual server IP address. This is 
what tells the switch that these are virtual service routers (VSRs). In this example. Layer 3 
bindings are left in their default configuration, which is disabled. 

Configure a virtual router using the following sequence of commands: 


» 

Virtual 

server 

4 

# /cfg/vrrp/vr 2 

(Select virtual router 2) 

» 

Virtual 

router 

2 

vrid 2 

(Set virtual router ID) 

» 

Virtual 

router 

2 

addr 200.200.200.100 

(Assign virtual router IP address) 

» 

Virtual 

router 

2 

if 5 

(Assign virtual router interface) 

» 

Virtual 

router 

2 

ena 

(Enable virtual router 2) 
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Repeat this sequence of commands for the following virtual routers: 

■ VR 4 - VRID 4 - IF 5 (associate with IP interface #5)—Address 200.200.200.101 

■ VR 6 - VRID 6 - IF 5 (associate with IP interface #5)—Address 200.200.200.103 

■ VR 8 - VRID 8 - IF 5 (associate with IP interface #5)—Address 200.200.200.104 

2. Configure virtual routers 1,3, 5, and 7. 

These virtual routers will act as the default gateways for the servers on each respective subnet. 
Because these virtual routers are survivable next hop/default gateways, they are called virtual 
interface routers (VIRs). 

Configure each virtual router listed below, using the sequence of commands in Step 1. 

■ VR 1 - VRID 1 - IF 1 (associate with IP interface 1)—Address 10.10.10.1 

■ VR 3 - VRID 3 - IF 2 (associate with IP interface 2)—Address 20.10.10.1 

■ VR 5 - VRID 5 - IF 3 (associate with IP interface 3)—Address 30.10.10.1 

■ VR 7 - VRID 7 - IF 4 (associate with IP interface 4)—Address 40.10.10.1 

3. Set the renter priority for each virtual router. 

Since you want Switch 1 to be the master router, you need to bump the default virtual router 
priorities (which are 100 to 101 on virtual routers 1-4) to force switch 1 to be the master for 
these virtual routers. 

Use the following sequence of commands: 


>> Virtual server 4 # /cfg/vrrp/vr 1 (Select virtual router 1) 

» Virtual router 1 prio 101 (Set virtual router priority) 


Apply this sequence of commands to the following virtual routers, assigning each a priority of 
101 : 

■ VR 2 - Priority 101 

■ VR 3 - Priority 101 

■ VR 4-Priority 101 

4. Configure priority tracking parameters for each virtual router. 

For this example, the best parameter(s) on which to track is Layer 4 ports (14pts). 

Use the following command: 


>> Virtual server 4# /cfg/vrrp/vr 1/track 14pts 
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This command sets the priority tracking parameter for virtual router 1, electing the virtual 
router with the most available ports as the master router. Repeat this command for the follow¬ 
ing virtual routers: 

■ VR 2 - Track 14pts VR 6 - Track 14pts 

■ VR 3 - Track 14pts VR 7 - Track 14pts 

■ VR 4 - Track 14pts VR 8 - Track 14pts 

Switch 1 configuration is complete. 

Task 4: Configuring Switch 2 

Use the following procedure to dump the configuration script (text dump) out of Switch 1: 

■ Using the Browser Based Interface (BBI) 

(a) You need a serial cable that is a DB-9 Male to DB-9 Female, straight-through (not a 
null modem) cable. 

(b) Connect the cable from a COM port on your computer to the console port on switch 1. 

(c) Open HyperTerminal (or the terminal program of your choice) and connect to the 
switch using the following parameters: Baud: 9600, Data Bits: 8, Parity: None, Stop 
Bits: 1, Flow Control: None. 

■ Using HyperTerminal 

(a) Only the Baud Rate and Flow Control options need to be changed from the default set¬ 
tings. 

(b) Once you connect to the switch, start logging your session in HyperTerminal (transfer/ 
capture text). 

(c) Save the file as “Customer Name” Switch 1, then type the following command in the 
switch command line interface: 

/cfg/dump 

A script will be dumped out. 

(d) Stop logging your session (transfer/capture text/stop). 
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Modify the script as follows: 

1. Open the text file that you just created and change the following: 

■ Delete anything above “Script Start.” 

■ Delete the two lines directly below “Script Start.” These two lines identify the switch from 
which the dump was taken and the date and time. If these two lines are left in, it will con¬ 
fuse Switch 2 when you dump in the file. 

■ Change the last octet in all the IP interfaces from .10 to .11. Find this in line: /cfg/ip/ 
if 1/addr 10.10.10.10. Simply delete the “0” and put in a “1.” Be sure to do this 
for all the IP interfaces, otherwise, you will have duplicate IP addresses in the network. 

2. Change the virtual router priorities. 

Virtual routers 1-4 need to have their priority set to 100 from 101, and virtual routers 5-7 need 
to have their priorities set to 101 from 100. You can find this in line /cf g/vrrp/vr 1 / 
vrid 1/if 1/prio 101. 

3. Scroll to the bottom of the text file and delete anything past “Script End.” 

4. Save the changes to the text file as “Customer Name” Switch 2. 

Move your serial cable to the console port on the second switch. Any configuration on it needs 
to be deleted by resetting it to factory settings, using the following command: 


>> Main# /boot/conf factory/reset 


You can tell if the switch is at factory default when you log on because the switch will prompt 
you if you want to use the step-by-step configuration process. When it does, respond: “No.” 

5. In HyperTerminal, go to transfer/send text file and send the Switch 2 text file. The configu¬ 
ration will dump into the switch. Simply type apply, then save. When you can type charac¬ 
ters in the terminal session again, reboot the switch (/boot/reset). 
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VRRP-Based Hot-Standby Configuration 

A hot-standby configuration allows all processes to failover to a backup switch if any type of 
failure should occur. The primary application for hot-standby redundancy is to avoid bridging 
loops when using the Spanning Tree Protocol (STP), IEEE 802.Id. 


NOTE — To use hot-standby redundancy, peer switches must have an equal number of ports. 


Clients 


Active 

Side 


Hub 


Standby 

Side 


7/CH 7\CH 

Interswitch link 



3 

S H 



S H 


Hub 


eaend 

. L4 ports are configured as Hot-Standby. 

. Crosslink is configured as Interswitch link. 


Servers 

Figure 11-10 Hot-Standby Configuration 


Figure 11-10 shows a classic network topology, designed with redundancy in mind. This topol¬ 
ogy contains bridging loops that would require the use of STP. In the typical network, STP 
failover time is 45-50 seconds, much longer than the typical failover rate using VRRP only. 


NOTE — In complex networks, STP convergence time can be much higher than 45-50 seconds. 


If VRRP was used in this configuration, it would require STP. An important factor to consider is 
that the switch would be affected by the slower failover time of STP even if VRRP were in use. 

While VRRP can be used without STP in this scenario, doing so would involve a more com¬ 
plex network configuration, requiring multiple subnets and/or VLANs and enabling IP for¬ 
warding to route between them. 
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By reducing complexity to a single subnet and not requiring routing (L3), hot-standby can be 
used. The key to hot-standby is that the interswitch link (the link between switches), does NOT 
participate in STP, so there are no loops in the topology (see Figure 11-10). STP does not need to 
be enabled, and the switch will have failover times similar to what would be the case with VRRP 

Configuration Procedure 

Configuration takes place after configuring SLB and VRRP with STP enabled: 

1. From the SLB menu, enable a hot-standby link on the Layer 4 ports; then enable inter¬ 
switch link on the crosslink. 


>> 

Main# /cfg/s 

lb/port 1 

(Select port 1 ) 

>> 

SLB 

Port 

Al# 

server ena 

(Enable the server) 

>> 

SLB 

Port 

Al# 

hotstan ena 

(Enable hot standby) 

>> 

SLB 

Port 

Al# 

../port 2 

(Select port 2) 

>> 

SLB 

Port 

A2# 

hotstan ena 

(Enable hot standby) 

>> 

SLB 

Port 

A2# 

. ./port 3 

(Select port 3) 

>> 

SLB 

Port 

A3# 

intersw ena 

( Enable inter-switch processing) 

>> 

SLB 

Port 

A3# 

../port 7 

(Select port 7) 

>> 

SLB 

Port 

A7 # 

client ena 

(Enable the client) 

>> 

SLB 

Port 

A7 # 

hotstan ena 

(Enable hot standby) 


2. From the VRRP menu, enable VRRP group mode; then enable hot-standby. 


>> Main# /cfg/vrrp/on (Enable VRRP) 

» VRRP# hotstan ena (Enable hot standby) 

» VRRP# group ena (Enable VR group) 


3. Sync the VRRP, SLB, and filter settings to the other switch (same ports). 


>> Main# /oper/slb/sync 


NOTE — Switches peering with each other must have an equal number of ports. 


4. Turn off STP after verifying that the network is stable. 


» Main# /cfg/stp 1/off 

(Disable STP group) 

>> Spanning Tree Group 1# save 

(Enable hot standby) 

>> Main# /boot/reset 

(Reset the switch) 


NOTE — You must reboot the switch for the hot-standby configuration to take effect. 
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Virtual Router Deployment Considerations 


Review the following issues described in this section to prevent network problems when 
deploying virtual routers: 

■ Mixing Active-Standby and Active-Active Virtual Routers 

■ Synchronizing Active/Active Failover 

■ Eliminating Loops with STP and VLANs 

■ Assigning VRRP Virtual Router ID 

■ Configuring the Switch for Tracking 

■ Synchronizing Configurations 

Mixing Active-Standby and Active-Active Virtual Routers 

If the network environment can support sharing, enable it for all virtual routers in the LAN. If 
not, use active-standby for all virtual routers. Do not mix active-active and active-standby vir¬ 
tual routers in a LAN. Mixed configurations have not been tested, may result in unexpected 
operational characteristics, and, therefore, are not recommended. 

Synchronizing Active/Active Failover 

The hot-standby failover required the primary and secondary switches to have identical config¬ 
urations and port topology. With VRRP and active/active failover, this is optional. Each switch 
can be configured individually with different port topology, SLB, and filters. If you would 
rather force two active/active switches to use identical settings, you can synchronize their con¬ 
figuration using the following command: 

/oper/sib/synch 

The sync command copies the following settings to the switch at the specified IP interface 
address: 

■ VRRP settings 

■ SLB settings (including port settings) 

■ Lilter settings (including filter port settings) 

■ Proxy IP settings 

If you perform the sync command, you should check the configuration on the target switch to 
ensure that the settings are correct. 

Lor more information on synchronizing configurations between two switches, see “Synchro¬ 
nizing Configurations” on page 201. 
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Eliminating Loops with STP and VLANs 

VRRP active/active failover is significantly different from the hot-standby failover method 
supported in previous releases. As shown in Figure 11-11, active-active configurations can 
introduce loops into complex LAN topologies. 


Internet 



Bridging Loop 

Figure 11-11 Loops in Active-Active Configuration 
Using Spanning Tree Protocol to Eliminate Loops 


VRRP generally requires Spanning Tree Protocol (STP) to be enabled in order to resolve 
bridge loops that usually occur in cross-redundant topologies, as shown in Figure 11-12. In this 
example, a number of loops are wired into the topology. STP resolves loops by blocking ports 
where looping is detected. 



Figure 11-12 Cross-Redundancy Creates Loops, But STP Resolves Them 

One drawback to using STP with VRRP is the failover response time. STP could take as long 
as 45 seconds to re-establish alternate routes after a switch or link failure. 
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Using VLANs to Eliminate Loops 

When using VRRP, you can decrease failover response time by using VLANs instead of STP 
to separate traffic into non-looping broadcast domains. An example is shown in Figure 11-13: 


Servers 


VLAN 1 is for switch-to-switch 
and external routing 

groups the first sub¬ 
switch with the Alteon 
Web Switches 
groups the second 
sub- switch with the 
Alteon Web switches 

Figure 11-13 Using VLANs to Create Nonlooping Topologies 

This topology allows STP to be disabled. On the Alteon Web switches, IP routing allows traf¬ 
fic to cross VLAN boundaries. The servers use the Alteon Web switches as default gateways. 
For port failure, traffic is rerouted to the alternate path within one health check interval (con¬ 
figurable between 1 and 60 seconds, with a default of 2 seconds). 

Assigning VRRP Virtual Router ID 

During the software upgrade process, VRRP virtual router IDs will be automatically assigned 
if failover is enabled on the switch. When configuring virtual routers at any point after 
upgrade, virtual router ID numbers (/cf g/vrrp/vr #/vrid) must be assigned. The virtual 
router ID may be configured as any number between 1 and 255. 

Configuring the Switch for Tracking 

Tracking configuration largely depends on user preferences and network environment. Con¬ 
sider the configuration shown in Figure 11-8 on page 184. Assume that the user wants the fol¬ 
lowing behavior on the network: 

■ The switch on the left will be the master router upon initialization. 

■ If the switch on the left is the master and it has one active server fewer than the switch on 
the right, it remains the master. 

■ The user wants this behavior because running one server down is less disruptive than 
bringing a new master online and severing all active connections in the process. 

■ If the switch on the left is the master and it has two or more active servers fewer than the 
switch on the right, the switch on the right becomes the master. 

■ If the switch on the right is the master, it remains the master even if servers are restored on 
the left-hand switch such that it has one fewer or an equal number of servers. 

■ If the switch on the right is the master and it has one active server fewer than the switch on 
the left, the switch on the left becomes the master. 
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The user can implement this behavior by configuring the switch for tracking as follows: 

1. Set the priority for the left-hand switch to the default value of 100. 

2. Set the priority for the right-hand switch to 96. 

3. On both switches, enable tracking based on the number of virtual routers in master mode 
on the switch and set the value = 5. 

4. On both switches, enable tracking based on the number of healthy real servers behind 
the VIP address that is the same as the IP address of the virtual server router on the 
switch and set the value = 6. 

Initially, the switch (Figure 11-8) on the left will have a priority of 100 (base value) + 5 (since 
it will initially be the master) + 24 (4 active real servers x 6 per real server) = 129. The switch 
on the right with have a priority of 96 (base value) + 24 (4 active real servers X 6 per real 
server) = 120. 

If one server attached to the left-hand switch fails, the left-hand switch’s priority will be 
reduced by 6 to 123. Since 123 is greater than 120 (the right-hand switch’s priority), the left- 
hand switch will remain the master. 

If a second server attached to the left-hand switch fails, the left-hand switch’s priority will be 
reduced by 6 more to 117. Since 117 is less than 120 (the right-hand switch’s priority), the 
right-hand switch will become the Master. At this point, the left-hand switch’s priority will fall 
by 5 more and the right-hand switch’s will rise by 5 because the switches are tracking how 
many Masters they are running. So, the left-hand switch’s priority will settle out at 112 and the 
right-hand switch’s priority at 125. 

When both servers are restored to the left-hand switch, that switch’s priority will rise by 12 (2 
healthy real servers X 6 per healthy server) to 124. Since 124 is less than 125, the right-hand 
switch will remain the master. 

If, at this point, a server fails on the right-hand switch, its priority will fall by 6 to 119. Since 
119 is less than 124, the left-hand switch will become the Master. Its priority will settle out at 
129 (since it’s now the master) while the right-hand switch’s will drop by 5 more to 114. 

As you can see from this example, the user’s goals were met by the configured tracking param¬ 
eters. 


NOTE — There is no shortcut to setting tracking parameters. The goals must first be set and the 
outcomes of various configurations and scenarios analyzed to find settings that meet the goals. 
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Synchronizing Configurations 

As noted above, each VRRP-capable switch is autonomous. Switches in a virtual router need 
not be identically configured. As a result, configurations cannot be synchronized automatically. 

For user convenience, it is possible to synchronize a configuration from one VRRP-capable 
switch to another using the /oper/slb/sync command. However, care must be taken 
when using this command to avoid unexpected results. All server load balancing, port configu¬ 
rations, filter configurations, and VRRP parameters can be synchronized using the /oper/ 
slb/synch command. 


NOTE — Before you synchronize the configuration between two switches, a peer must be con¬ 
figured on each switch. Switches being synchronized must use the same administrator pass¬ 
word. 


Configure the two switches as peers to each other. From Switch 1, configure Switch 2 as a peer 
and specify its IP address as follows: 


>> 

Main # /cfg/slb/sync 

(Select the synchronization menu) 

>> 

Config Synchronization # peer 1 

(Select a peer) 

>> 

Peer Switch 1 # addr <ip address> 

(Assign switch 2 IP address) 

>> 

Peer Switch 1 # enable 

(Enable peer switch) 


Similarly, from switch #2, configure switch # 1 as a peer and specify its IP address as follows: 


» 

Main # /cfg/slb/sync 

(Select the synchronization menu) 

» 

Config Synchronization # peer 2 

(Select a peer) 

» 

Peer Switch 2 # addr <ip address> 

(Assign switch 1 IP address) 

» 

Peer Switch 2 # enable 

(Enable peer switch) 


Port specific parameters, such as what filters are applied and enabled on what ports, are part of 
what is pushed by the / oper/sib/synch command. Thus, if the /oper/sib/synch 
command is used, it is highly recommended that the hardware configurations and network con¬ 
nections of all switches in the virtual router be identical; that is, each switch should be the 
same model, have the same line cards in the same slots (if modular) and have the same ports 
connected to the same external network devices. Otherwise, unexpected results may occur 
when the / oper/sib/synch command attempts to configure a non-existent port or applies 
an inappropriate configuration to a port. 
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Part 3: Advanced Web 
Switching 


Web OS advanced Web switching can parse requests and classify flows using URLs, host tags, 
and cookies so that each request can be isolated and treated intelligently. This section details 
the following advanced Web switching applications: 

■ Global Server Load Balancing 

■ Firewall Load Balancing 

■ Virtual Private Network Load Balancing 

■ Content Intelligent Switching 

■ Persistence 

■ Bandwidth Management 
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Chapter 12 

Global Server Load Balancing 


This chapter provides information for configuring Global Server Load Balancing (GSLB) 
across multiple geographic sites. The following topics are covered: 

■ “GSLB Overview” on page 206 

■ “Configuring GSLB” on page 209 

■ “IP Proxy for Non-HTTP Redirects” on page 220 

■ “Verifying GSLB Operation” on page 223 

■ “Configuring Client Site Preferences” on page 224 

■ “Using Border Gateway Protocol for GSLB” on page 227 
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GSLB Overview 


GSLB allows you to balance server traffic load across multiple physical sites. Alteon Web¬ 
Systems GSLB implementation takes into account an individual site’s health, response time, 

and geographic location to smoothly integrate the resources of the dispersed server sites for 

complete global performance. 

Benefits 

GSLB meets the following demands for distributed network services: 

■ High content availability is achieved through distributed content and distributed decision 
making. If one site becomes disabled, the others become aware of it and take up the load. 

■ There is no latency during client connection set up. Instant site hand-off decisions can be 
made by any distributed switch. 

■ The best performing sites get a majority of traffic over a given period of time but are not 
overwhelmed. 

■ Switches at different sites regularly exchange information through the Distributed Site 
State Protocol (DSSP) and can trigger exchanges when any site’s health status changes. 
This ensures that each active site has valid state knowledge and statistics. 

■ GSLB implementation takes geography as well as network topology into account. 

■ Creative control is given to the network administrator or Webmaster to build and control 
content by user, location, target application, and more. 

■ GSLB is easy to deploy, manage, and scale. Switch configuration is straight forward. 
There are no complex system topologies involving routers, protocols, and so forth. 

■ Flexible design options are provided. 

■ All IP protocols are supported. 
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How GSLB Works 

GSLB is based on the Domain Name System (DNS) and proximity by source IP address. In Fig¬ 
ure 12-1, a client is using a browser to view the Web site for the Foo Corporation at “www.foo- 
corp.com.” The Foo Corporation has two Web sites: one in California, and one in Denver, each 
with identical content and available services. Both Web sites have an Alteon Web switch config¬ 
ured for GSLB. These switches are also configured as the Authoritative Name Servers for 
“www.foocorp.com.” 


Client Site 



Figure 12-1 DNS Resolution with Global Server Load Balancing 

The DNS resolution for GSLB is described in detail in the following procedure: 

1. The client Web browser requests the “www.foocorp.com” IP address from the local DNS. 

2. Client’s DNS asks its upstream DNS, which in turn asks the next, and so on, until the 
address is resolved. 

Eventually, the request reaches an upstream DNS server that has the requested IP address 
information on hand or the request reaches one of the Foo Corporation’s DNS servers. 

3. The Foo Corporation’s California DNS has been configured to use the local Web switch 
with GSLB software as the authoritative name server for “www.foocorp.com.” 
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4. The California Web switch responds to the DNS request, listing the IP address with the 
current best service. 

Each switch with GSLB software is capable of responding to the client’s name resolution 
request. Since each switch regularly checks and communicates health and performance infor¬ 
mation with its peers, either switch can determine which site(s) are best able to serve the cli¬ 
ent’s Web access needs. It can respond with a list of IP addresses for the Foo Corporation’s 
distributed sites, prioritized by performance, geography, and other criteria. 

In this case, the California Web switch knows that Foo Corp. Denver currently provides better 
service, and lists Foo Corp. Denver’s virtual server IP address first when responding to the 
DNS request. 

5. The client connects to Foo Corp. Denver for the best service. 

The client’s Web browser will use the IP address information gained from the DNS request to 
open a connection to the best available site. The IP addresses represent virtual servers at any 
site, which are locally load balanced according to regular SFB configuration. 

If the site serving the client HTTP content suddenly experiences a failure (no healthy real serv¬ 
ers) or becomes overloaded with traffic (all real servers reach their maximum connection 
limit), the switch issues an HTTP Redirect and transparently causes the client to connect to 
another peer site. 

The end result is that the client gets quick, reliable service with no latency and no special cli¬ 
ent-side configuration. 
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Configuring GSLB 

Configuring GSLB is simply an extension of the configuration procedure for SLB. The process 
is summarized as follows: 

■ Use the administrator login to connect to the switch you want to configure. 

■ Activate SLB and GSLB software keys. See the Web OS 9.0 Command Reference for 
details. 

■ Configure the switch at each site with basic attributes. 

□ Configure the switch IP interface. 

□ Configure the default gateways. 

■ Configure the switch at each site to act as the DNS server for each service hosted on its 
virtual servers. Also, configure the local DNS server to recognize the switch as the author¬ 
itative DNS server for the hosted services. 

■ Configure the switch at each site for local SLB. 

□ Define each local real server. 

□ Group local real servers into real server groups. 

□ Define the local virtual server with its IP address, services, and real server groups. 

□ Define the switch port states. 

□ Enable SLB. 

■ Finally, configure each switch so that it recognizes its remote peers. 

□ Configure a remote real server entry on each switch for each remote service. 

□ Add the remote real server entry to an appropriate real server group. 

□ Enable GSLB. 


NOTE — URL-based server load balancing is compatible with GSLB. Cookie-based persistence 
is compatible with GSLB, Cookie Rewrite mode and Cookie Insert mode). 
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Example GSLB Togology 


Consider the following example network: 


California Site 

200.200.200.X Network 


Denver Site 

174.14.70.X Network 



IP Interface: Default Gateway: 

200 . 200 . 200.100 200 . 200 . 200.101 
Virtual Server: 

200 . 200 . 200.1 


Internet 



Default Gateway: IP Interface: 
174 . 14 . 70.101 174 . 14 . 70.100 


DNS Server: 
174 . 14 . 70.102 


Web Servers: 
200 . 200 . 200.2 
200 . 200 . 200.3 


Virtual Server: 
174 . 14 . 70.1 


Web Servers: 

174 . 14 . 70.2 

174 . 14 . 70.3 


Figure 12-2 GSLB Topology Example 

In the following examples, many of the options are left to their default values. See “Additional 
Server Load Balancing Options” on page 78 for more options. 

GSLB Requirements 

The following is required prior to configuration: 

■ You must be connected to the switch Command Line Interface (CLI) as the administrator. 

■ Both of the following optional software keys must be activated: 


□ SLB 


□ GSLB 


NOTE — For details about any of the processes or menu commands described in this example, 
see the Web OS Command Reference. 
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Task 1: Configure the Basics at the California Site 

1. If the Browser-Based Interface (BBI) is to be used for managing the California switch, 
change its service port. 

GSLB uses service port 80 on the IP interface for DSSP updates. By default, the Web OS 
Browser-Based Interface (BBI) also uses port 80. Both services cannot use the same port. If the 
BBI is enabled (see the / cfg/sys/http command in Chapter 7 of the Web OS 9.0 Command 
Reference ), configure it to use a different port. 


For example, enter the following command to change the BBI port to 8080: 


>> # /cfg/sys 

(Select the System menu) 

>> System# wport 8080 

(Set service port 8080for BBI) 


2. On the California switch, define an IP interface. 

The switch IP interface responds when asked to resolve client DNS requests. The IP interface 
must have an IP route to the local real servers. The switch uses this path to determine if the real 
servers can be reached via TCP/IP. 


To configure an IP interface for this example, enter these commands from the CLI: 


» 

System# /cfg/ip/if 1 

(Select IP interface 1) 

» 

IP Interface 1# addr 200.200.200.100 

(Assign IP address for the interface) 

» 

IP Interface 1# ena 

(Enable IP interface 1) 


NOTE — This example assumes that all ports and IP interfaces use default VLAN 1, requiring 
no special VLAN configuration for the ports or IP interface. 


3. On the California switch, define the default gateway. 

The router at the edge of the site acts as the default gateway to the Internet. To configure the 
default gateway for this example, enter these commands from the CLI: 

>> IP Interface 1# ../gw 1 (Select default gateway 1) 

>> Default gateway 1# addr 200.200.200.101 (Assign IP address for the gateway) 
» Default gateway 1# ena (Enable default gateway 1) 


4 . Configure the local DNS server to recognize the local GSLB switch as the authoritative 
name server for the hosted services. 

Determine the domain name that will be distributed to both sites and the host name for each 
distributed service. In this example, the California DNS server is configured to recognize 
200.200.200.100 (the IP interface of the California GSLB switch) as the authoritative name 
server for “www.foocorp.com.” 
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Task 2: Configure the California Switch for Standard SLB 

1. Assign an IP address to each of the real servers in the local California server pool. 

The real servers in any real server group must have an IP route to the switch that will perform 
the SLB functions. This is most easily accomplished by placing the switches and servers on the 
same IP subnet, although advanced routing techniques can be used as long as they do not vio¬ 
late the topology rules outlined in “Network Topology Requirements” on page 72. 

For this example, the host real servers have IP addresses on the same IP subnet: 

Table 12-1 GSLB Example: California Real Server IP Addresses 


Real Server 

IP address 

Server A 

200.200.200.2 

Server B 

200.200.200.3 


2. On the California switch, define each local real server. 

For each local real server, you must assign a real server number, specify its actual IP address, 
and enable the real server. For example: 


>> 

Default gateway 

1# 

/cfg/slb/real 1 

(Server A is real server 1) 

>> 

Real 

server 

i# 

rip 

200.200.200.2 

(Assign IP address to server A) 

>> 

Real 

server 

i# 

ena 


(Enable real server 1) 

>> 

Real 

server 

i# 

../real 2 

(Server B is real server 2) 

>> 

Real 

server 

2# 

rip 

200.200.200.3 

(Assign IP address to ser\<er B) 

>> 

Real 

server 

2# 

ena 


(Enable real server 2) 


3. On the California switch, define a real server group. 

Combine the real servers into one service group and set the necessary health checking parame¬ 
ters. In this example, HTTP health checking is used to ensure that Web content is being served. 
If the index. html file is not accessible on a real server during health checks, the real server 
will be marked as down. 


» 

Real 

server 

2# . . 

/group 1 

f Select real server group 1) 

» 

Real 

server 

group 

1# 

add 1 

(Add real server 1 to group 1) 

» 

Real 

server 

group 

1# 

add 2 

(Add real server 2 to group 1) 

» 

Real 

server 

group 

1# 

health http 

(Use HTTP for health checks) 

» 

Real 

server 

group 

1# 

content index 

html (Set URL content for health checks) 


212 ■ Chapter 12: Global Server Load Balancing 


Alteon ((^Systems 

050159A. May 2001 







Web OS 9.0 Application Guide 


4. On the California switch, define a virtual server. 

All client requests will be addressed to a virtual server IP address defined on the switch. Cli¬ 
ents acquire the virtual server IP address through normal DNS resolution. HTTP uses well- 
known TCP port 80. In this example, HTTP is configured as the only service running on this 
virtual server IP address and is associated with the real server group. For example: 


>> 

Real server group 

i# 

./virt 1 


(Select virtual server 1) 

» 

Virtual 

server 

i# 

vip 

200.200. 

200.1 

(Assign a virtual sewer IP address) 

>> 

Virtual 

Server 

i# 

service 80 



>> 

Virtual 

server 

i 

http 

Service# 

group 1 

(Associate virtual port to real group) 

>> 

Virtual 

server 

i 

http 

Service# 

../ena 

(Enable virtual sewer) 


NOTE — This configuration is not limited to HTTP services. For a list of other well-known 
TCP/IP services and ports, see Table 6-3 on page 78. 


5. On the California switch, define the type of Layer 4 traffic processing each port must 
support. 

In this example, the following ports are being used on the Web switch: 


Table 12-2 GSLB Example: California Alteon 180 Port Usage 


Port 

Host 

Layer 4 Processing 

1 

Server A 

Server 

2 

Server B 

Server 

6 

Default Gateway Router. This connects the switch to the Internet 
where all client requests originate. 

Client 


The ports are configured as follows: 


>> 

Virtual 

server 1# /cfg/slb/port 1 

(Select physical switch port 1) 

>> 

SLB 

port 

1# 

server ena 

(Enable sewer processing on port 1) 

>> 

SLB 

port 

1# 

../port 2 

(Select physical switch port 2) 

>> 

SLB 

port 

2# 

server ena 

(Enable sewer processing on port 2) 

» 

SLB 

port 

2# 

../port 6 

(Select physical switch port 6) 

» 

SLB 

port 

6# 

client ena 

(Enable client processing on port 6) 


6. On the California switch, enable SLB. 


» SLB port 6# /cfg/slb 

(Select the SLB Menu) 

>> Layer 4# on 

(Turn SLB on) 
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Task 3: Configure the California Site for GSLB 

1. On the California switch, define each remote site. 


When you start configuring at the California site, California is local and Denver is remote. Add 
and enable the remote switch’s IP address interface. In this example, there is only one remote 
site: Denver, with an IP interface address of 174.14.70.100. The following commands are used: 


>> 

Layer 4# gslb/site 1 

(Select remote site 1) 

>> 

Remote site 1# prima 174.14.70.100 

(Define remote interface) 

>> 

Remote site 1# ena 

(Enable remote site 1) 


Each additional remote site would be configured in the same manner. You can enable up to 64 
remote sites with a total aggregate of 2048 service/site combinations. 


2. On the California switch, assign each remote distributed service to a local virtual server. 


NOTE — Take care to note where each configured value originates. If it is not clearly under¬ 
stood, this step can result in improper configuration. 


The local California site is configured to recognize the services offered at the remote Denver 
site. To do this, configure one real server entry on the California switch for each virtual server 
located at each remote site. Since there is only one remote site (Denver) with only one virtual 
server, only one more local real server entry is needed at the California site. 

The new real server entry is configured with the IP address of the remote virtual server rather 
than the usual IP address of a local physical server. 

Also, the remote property is enabled, and the real server entry is added to the real server group 
under the local virtual server for the intended service. Finally, since the real server health 
checks are performed across the Internet, the health-checking interval should be increased to 
30 or 60 seconds to avoid generating excess traffic. For example: 


» 

Remote site 

i# 

/cfg/slb/real 3 

(Create an entry for real sen’er 3) 

» 

Real 

server 

3# 

rip 174.14.70.1 

(Set remote virtual sen’er IP address) 

» 

Real 

server 

3# 

remote enable 

(Define the real sen’er as remote) 

» 

Real 

server 

3# 

inter 60 

(Set a high health check interval) 

» 

Real 

server 

3# 

ena 

(Enable the real sen’er entry) 

» 

Real 

server 

3# 

../group 1 

(Select appropriate real server group) 

» 

Real 

server 

group 1# add 3 

(Add real sen’er 3 to the group 1) 


NOTE — The IP address of the real server being added is that of the virtual server on the remote 
switch. Do not confuse this value with the IP interface address on the remote switch. 
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3. On the California switch, define the domain name and host name for each service hosted 
on each virtual server. 

In this example, the domain name for the Foo Corporation is “foocorp.com,” and the host 
name for the only service (HTTP) is “www.” These values are configured as follows: 


» Real server group 1# . ./virt 1 
» Virtual server 1# dname foocorp.com 
» Virtual server 1# service 80/hname www 

(Select virtual server 1 ) 

(Define domain name) 

(Define HTTP host name) 

If other services were defined (such as FTP), additional hostname entries would be made. 

On the California switch, turn on GSLB. 


>> Virtual server 1# .. /gslb 
>> Global SLB# on 

(Select the GSLB Menu) 

(Activate GSLB for the switch) 

Apply and verify the configuration. 

» Global SLB# apply 
» Global SLB# cur 
>> Global SLB# /cfg/slb/cur 

(Make your changes active) 

(View current GSLB settings) 

(View current SLB settings) 

Examine the resulting information. If any settings are incorrect, make and apply any appropri¬ 
ate changes, and then check again. 

Save your new configuration changes. 


>> Layer 4# save 

(Save for restore after reboot) 


Task 4: Configure the Basics at the Denver Site 

Following the same procedure described for California (see “Example GSLB Togology” on 
page 210), configure the Denver site as follows: 

1. If the Web OS BBI is to be used for managing the Denver switch, change its service port. 


» # /cfg/sys 

(Select the System menu) 

» System# wport 8080 

(Set sendee port 8080for BBI) 
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2. On the Denver switch, define an IP interface. 


>> 

# 

/cfg/ip/if 

1 

(Select IP interface I) 

>> 

IP 

Interface 

1# addr 174.14.70.100 

(Assign IP address for the interface) 

>> 

IP 

Interface 

1# ena 

(Enable IP interface 1) 


3. On the Denver switch, define the default gateway. 


>> IP Interface 1# ../gw 1 (Select default gateway 1) 

» Default gateway 1# addr 174.14.70.101 (Assign IP address for the gateway) 

» Default gateway 1# ena (Enable default gateway 1) 


4 . Configure the local DNS server to recognize the local GSLB switch as the authoritative 
name server for the hosted services. 

The Denver DNS server is configured to recognize 174.14.70.100 (the IP interface of the Den¬ 
ver GSLB switch) as the authoritative name server for “www.foocorp.com.” 

Task 5: Configure the Denver Switch for Standard SLB 

1. Assign an IP address to each of the real servers in the local Denver server pool. 

Table 12-3 Denver Real Server IP Addresses 


Real Server 

IP address 

Server C 

179.14.70.2 

Server D 

179.14.70.2 


2. On the Denver switch, define each local real server. 


>> 

Default gateway 

1# 

/cfg/slb/real 1 

(Server C is real ser\>er 1) 

>> 

Real 

server 

i# 

rip 

179.14.70.2 

(Assign IP address for Seryer C) 

>> 

Real 

server 

i# 

ena 


(Enable real server 1) 

>> 

Real 

server 

i# 

../real 2 

(Seryer D is real seryer 2) 

>> 

Real 

server 

2# 

rip 

179.14.70.3 

(Assign IP address for Seryer D) 

>> 

Real 

server 

2# 

ena 


(Enable real server 2) 
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3. On the Denver switch, define a real server group. 


>> 

Real 

server 

2# . . 

/group 1 

(Select real ser\>er group 1) 

>> 

Real 

server 

group 

1# 

add 1 

(Add real server 1 to group 1) 

>> 

Real 

server 

group 

1# 

add 2 

(Add real server 2 to group 1) 

>> 

Real 

server 

group 

1# 

health http 

f Use HTTP for health checks) 

>> 

Real 

server 

group 

1# 

content index 

html (Set URL content for health checks) 


4. On the Denver switch, define a virtual server. 


» 

Real server group 

i# 

./virt 1 

(Select virtual server 1) 

» 

Virtual 

server 

i# 

vip 

179.14.70.1 

(Assign IP address) 

» 

Virtual 

server 

i# 

service http 

(Select the HTTP service menu) 

» 

Virtual 

server 

i 

http 

service# group 1 

(Associate virtual port to real group) 

» 

Virtual 

server 

i 

http 

service# .. /ena 

(Enable the virtual server) 


5. On the Denver switch, define the type of Layer 4 processing each port must support. 

In this example, the following ports are being used on the Alteon 180 Web switch: 

Table 12-4 Web Host Example: Alteon 180 Port Usage 


Port 

Host 

Layer 4 Processing 

3 

Server C 

Server 

4 

Server D 

Server 

5 

Default Gateway Router. This connects the switch to the Internet 
where all client requests originate. 

Client 


The ports are configured as follows: 


>> 

Virtual 

server 1# /cfg/slb/port 3 

(Select physical switch port 3) 

>> 

SLB 

port 

3# 

server ena 

(Enable server processing on port 3) 

>> 

SLB 

port 

3# 

../port 4 

(Select physical switch port 4) 

>> 

SLB 

port 

4# 

server ena 

(Enable server processing on port 4) 

>> 

SLB 

port 

4# 

../port 5 

(Select physical switch port 5) 

>> 

SLB 

port 

5# 

client ena 

(Enable client processing on port 5) 


6. On the Denver switch, enable SLB. 


» SLB port 5# /cfg/slb 

(Select the SLB Menu) 

>> Layer 4# on 

(Turn SLB on) 
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Task 6: Configure the Denver Site for GSLB 

Following the same procedure described for California (see “Task 3: Configure the California 
Site for GSLB” on page 214), configure the Denver site as follows: 

1. On the Denver switch, define each remote site. 

When you start configuring at the Denver site, Denver is local and California is remote. Add 
and enable the remote switch’s IP address interface. In this example, there is only one remote 
site: California, with an IP interface address of 200.200.200.100. The following commands are 
used: 


>> 

Layer 4# gslb/site 1 

(Select remote site 1) 

>> 

Remote site 1# prima 200.200.200.100 

(Define remote IP interface address) 

>> 

Remote site 1# ena 

(Enable remote site 1) 


Each additional remote site would be configured in the same manner. You can enable up to 64 
remote sites with a total aggregate of 2048 service/site combinations. 


2. On the Denver switch, assign each remote distributed service to a local virtual server. 


NOTE — Take care to note where each configured value originates. If it is not clearly under¬ 
stood, this step can result in improper configuration. 

In this step, the local Denver site is configured to recognize the services offered at the remote 
California site. As before, configure one real server entry on the Denver switch for each virtual 
server located at each remote site. Since there is only one remote site (California) with only 
one virtual server, only one more local real server entry is needed at the Denver site. 

The new real server entry is configured with the IP address of the remote virtual server, rather 
than the usual IP address of a local physical server. 

Also, the remote property is enabled, and the real server entry is added to the real server group 
under the local virtual server for the intended service. Finally, since the real server health 
checks are headed across the Internet, the health-checking interval should be increased to 30 or 
60 seconds to avoid generating excess traffic. 
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For example: 


>> 

Remote site 

i# 

/cfg/slb/real 3 

(Create an entry for real server 3) 

>> 

Real 

server 

3# 

rip 200.200.200.1 

(Set remote virtual sen’erIP address) 

>> 

Real 

server 

3# 

remote enable 

(Define the real server as remote) 

>> 

Real 

server 

3# 

inter 60 

(Set a high health check interval) 

>> 

Real 

server 

3# 

ena 

(Enable the real server entry) 

>> 

Real 

server 

3# 

../group 1 

(Select appropriate, real server group) 

>> 

Real 

server 

group 1# add 3 

(Add real server 3 to group 1) 


NOTE — The IP address of the real server being added is that of the virtual server on the remote 
switch. Do not confuse this value with the IP interface address on the remote switch. 


3. On the Denver switch, define the domain name and host name for each service hosted on 
each virtual server. 

These will be the same as for the California switch: the domain name is “foocorp.com,” and 
the host name for the HTTP service is “www.” These values are configured as follows: 


» Real server group 1# .. /virt 1 
» Virtual server 1# dname foocorp.com 

» Virtual server 1# service 80 
» Virtual server 1 http# hname www 


(Select virtual server 1) 

(Define domain name) 

(Select HTTP for virtual ser\>er) 
(Define HTTP hostname) 


On the Denver switch, turn on GSLB. 


>> Virtual server 1 http# /cfg/ 

slb/gslb/on (Activate GSLB for the switch) 

Apply and verify the configuration. 

>> Global SLB# apply 

(Make your changes active) 

>> Global SLB# cur 

(View current GSLB settings) 

>> Global SLB# /cfg/slb/cur 

(View current SLB settings) 


Examine the resulting information. If any settings are incorrect, make and apply any appropri¬ 
ate changes, and then check again. 

6. Save your new configuration changes. 


>> Layer 4# save 


(Save for restore after reboot) 
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IP Proxy for Non-HTTP Redirects 


Web OS software allows you to configure GSLB remote servers to redirect client requests using 
a load-balancing mechanism called IP proxy. Under normal GSLB, client requests for HTTP 
applications are automatically redirected to the location with the best response and least load for 
the requested content. But if the client requests non-HTTP applications (FTP, POP3, or SMTP 
for example), then a proxy IP address is used on the client port which initiates a redirect only if 
resources are unavailable at the first site. 


NOTE — This feature should be used as a method of last resort for GSLB implementations in 
topologies where the remote servers are usually virtual server IP addresses in other Alteon 
Web switches. 


Figure 12-3 illustrates the process of HTTP and non-HTTP redirects in a GSLB environment. 


Client Site 



Proxy IP address is 
configured on Client 
port for non-HTTP 
applications. 


HTTP Applications 
Non HTTP Applications - 


Site 1 


Web Switch 


Web 

Servers 


Site 2 

DNS 


Figure 12-3 Using Proxy IP for Non-HTTP Redirects 
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Table 12-5 explains the process in detail. In this example, the initial DNS request from the cli¬ 
ent reaches Site 2, but Site 2 has no available services. 


Table 12-5 HTTP Versus Non-HTTP Redirects 



Web Switch at Site 2 

Web Switch at Site 1 

HTTP application 

Client DNS request reaches Site 2. 

Resources are unavailable at Site 2. 

Site 2 sends a response to Client with Site l’s 
virtual server IP address. 

Client resends request to Site 1. 

Resources are available at Site 1. 

Site 1 completes three-way handshake with cli¬ 
ent. 

Non-HTTP application 

Client DNS request reaches Site 2. 

Resources are unavailable at Site 2. 

Site 2 sends a request to Site 1 with Site 2’s 
proxy IP address as the source IP address and 
the virtual server IP address of Site 1 as the des¬ 
tination IP address. 

Site 1 processes the client proxy IP request. 
Resources are available at Site 1. 

Site 1 returns request to proxy IP port on Site 2. 
Site 2 completes the three-way handshake with 
Client. 


How IP Proxy Works 

Figure 12-4 shows two GSLB sites, each with one local virtual server serviced by two real 
servers in real server group 1. The applications being load balanced are HTTP and POP3. Any 
request that cannot be serviced locally is sent to the peer site. HTTP requests are sent to the 
peer site using HTTP Redirect. Any other application request will be sent to the peer site using 
the IP proxy feature. 

California Site #1 Denver: Site #2 

200.200.200.X Network 174.14.70.X Network 



1 Proxy Disabled For 
' Local Real Servers 

Alt! 

i 


Service requests are always served by 
local real servers if available. 


Proxy Disabled For 
Local Real Servers 


Web Switch 


Proxy IP Address: 
200.200.200.4 



Internet 



HTTP/POP3 
Local Servers: 
200 . 200 . 200.2 
200.200.200.3 

Remote Server: 
174.14.70.1 


Virtual Server: 
200 . 200 . 200.1 


Default Gateway 


Proxy IP Address: 
174.14.70.4 


Default Gateway 


Virtual Server: 
174.14.70.1 


If local real servers cannot service the request, 
the remote server is used via proxy. 


Mna^ 


HTTP/POP3 
Local Servers: 

174.14.70.2 

174.14.70.3 

Remote Server: 
200 . 200 . 200.1 


Figure 12-4 POP3 Request Fulfilled via IP Proxy 

The following procedure explains the three-way handshake between the two sites and the cli¬ 
ent for a non-HTTP application (POP3). When POP3 processes at Site 1 terminate because of 
operator error, the following events occur to allow POP3 requests to be fulfilled: 
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1. A user POP3 TCP SYN request is received by the virtual server at Site 1. The switch at 
that site determines that there are no local resources to handle the request. 

2. The Site 1 switch rewrites the request such that it now contains a client proxy IP address 
as the source IP address, and the virtual server IP address at Site 2 as the destination IP 
address. 

3. The switch at Site 2 receives the POP3 TCP SYN request to its virtual server. The request 
looks like a normal SYN frame, so the performs normal local load-balancing. 

4. Internally at Site 2, the switch and the real servers exchange information. The TCP SYN 
ACK from Site 2’s local real server is sent back to the IP address specified by the proxy IP 
address. 

5. The Site 2 switch sends the TCP SYN ACK frame to Site 1, with Site 2’s virtual server IP 
address as the source IP address, and Site l’s proxy IP address as the destination IP 
address. 

6. The switch at Site 1 receives the frame and translates it, using Site l’s virtual server IP 
address as the source IP address and the client’s IP address as the destination IP address. 

This cycle continues for the remaining frames to transmit all the client’s mail, until a FIN 
frame is received. 

Configuring Proxy IP Addresses 

In keeping with the example starting on page 210, the switch at Site 1 in California is config¬ 
ured with switch port 6 connecting to the default gateway and real server 3 representing the 
remote server in Denver (see Table 12-2 on page 213). The following commands are used to 
configure the proxy IP address on Site 1 in California: 


NOTE — If any port is configured with a proxy IP address, then all ports (except port 9) must 
be configured with a unique proxy IP address prior to enabling Virtual Matrix Architecture 
(VMA). Once they are configured, proxy IP addresses not in use can be disabled. 


>> # /cfg/slb/port 6 

>> SLB port 6# pip 200.200.200.4 

>> SLB port 6# proxy enable 

>> SLB port 6 ../real 1/proxy disable 


>> 

Real 

server 

i# 

. . /real 

2/proxy disable 

>> 

Real 

server 

2# 

. ./real 

3/proxy enable 

>> 

Real 

server 

3# 

apply 


>> 

Real 

server 

3# 

save 



(Select port to default gateway) 
(Set unique proxy IP address) 

(Enable proxy for switch port 6) 

(Disable local real setyer proxy) 
(Disable proxy for local setyer) 
(Enable proxy for remote setyer) 
(Apply configuration changes) 
(Save configuration changes) 
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If you want to configure proxy IP addresses on Site 2, the following commands are issued on 
the Denver switch: 


>> # /cfg/slb/port 5 

>> SLB port 5# pip 174.14.17.4 

>> SLB port 5# proxy enable 

>> SLB port 5# ../real 1/proxy disable 

>> Real server 1# ../real 2/proxy disable 

>> Real server 2# ../real 3/proxy enable 

>> Real server 3# apply 

>> Real server 3# save 


(Select port to default gateway) 
(Set unique proxy IP address) 


(Enable proxy for switch port 5) 
(Disable local real server proxy) 
(Disable local real server proxy) 
(Enable proxy for remote sen’er) 
(Apply configuration changes) 


(Save configuration changes) 


Verifying GSLB Operation 


■ Use your browser to request the configured service (www. f oocorp . com in the previous 
example). 

■ Examine the /inf o/slb information on each switch. 

■ Check to see that all SLB parameters are working according to expectation. If necessary, 
make any appropriate configuration changes and then check the information again. 

■ Examine the following statistics on each switch: 

□ /stats/slb/gslb/virt <virtual server number> 

□ /stats/slb/gslb/group <real server group number> 

□ /stats/slb/maint 
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Configuring Client Site Preferences 


Internet Assigned Numbers Authority (IANA), the central coordinator for the assignment of 
unique parameter values for internet protocols, does not provide sufficient geographic separa¬ 
tion of client proximity information. As a result, large ISP partners cannot use their own geo¬ 
graphic data to determine GSLB site selection based on client location. However, using static 
“client-to-site” mapping in Web OS software, you can configure client proximity tables to select 
GSLB sites based on client location. 


The use of a static client/site database allows you to customize the client environment. The 
proximity database is limited to 128 entries. The GSLB client proximity table is supported for 
HTTP protocol. 


Figure 12-5 illustrates GSLB proximity tables. The clients sends a request to the DNS server, 
which is forwarded to the master switch. The master switch looks through its proximity table 
and returns the request to the DNS server with the virtual server IP address of the preferred 
site. The DNS server sends a new request through the Internet and connects the client to the 
preferred site. 



4.CLIENT REQUEST FORWARDED 
TO NEAREST LOCATION 


DATABASE FIELDS 

<IP ADDRESS> <NETMASK> <VIP> 


3.MASTER 

SWIT CH LOOKS AT 

DATABASE AND RESPONDS 


1. CLIENT SENDS REQUEST 
TO LOCAL DNS SERVER 


2. DNS REQUEST 
SENT TO MASTER 
SWIT CH 


Figure 12-5 GSLB Proximity Tables: How They Work 


The following example illustrated in Figure 12-6 shows how to add entries into a GSLB prox¬ 
imity table. Two client networks, A and B, are configured in the proximity table on the master 
switch at Site 4. Client A with a subnet address of 205.178.13.0 is configured with static 
entries for preferred Sites 1 and 3. Client B, with a subnet address of 204.165.0.0, is configured 
with static entries for preferred Sites 2 and 4. 
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Client A, with a source IP address of 205.178.13.10, initiates a request that is sent to the local 
DNS server. The local DNS server is configured to forward requests to the DNS server at Site 
4. The Web switch at Site 4 looks up its proximity table and finds Client A prefers to connect 
to Sites 1 or 3. Similarly, Client B’s requests are always forwarded to Sites 2 or 4. 


Client Site A 


Client Site B 

204.165.0.0 



1. Client sites A and B send requests to 
their DNS servers which are forwarded 
to the master switch at Site 4. 

2. The master switch looks through its 
proximity table and responds to the 
DNS request by providing the virtual 
IP address of the preferred site. 

3. The client sends out a new request 
and connects to the preferred site. 


Master switch returns 
Client's request with the 
VIP of the preferred site 


Web Switch 
Web IF: 2.2.2.2/24 

Servers VIP: 2.2.2.100 


Web Switch 
IF: 3.3.3.3/16 Web 
VIP: 3.3.3.100 Servers 


Figure 12-6 Configuring Client Proximity Table 
You can add static entries in the proximity table for up to 128 client networks. 


NOTE — Web OS allows you to configure a single domain only and for each client subnet you 
can configure up to two preferred sites. 


The Web switch forwards the client request based on the minimum available sessions and 
response time between the two preferred sites. 
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Use the following commands to configure a proximity table on the Web switch at Site 4: 


>> 

# 

/cfg/slb/gslb/lookup/lookups ena 

(Enable the lookup or proximity table) 

>> 

# 

dname nortelnetworks.com 

(Select the domain name) 

>> 

# 

network 1 

(Select Client A subnet) 

>> 

# 

sip 205.178.13.0 

(Assign source address for Client A) 

>> 

# 

mask 255.255.255.0 

(Assign the mask for Client A) 

>> 

# 

vipl <virtual server IP addr of Site 3> 

(Select preferred Site 3) 

>> 

# 

vip2 <virtual server IP addr of Site 1 > 

(Select preferred Site 1) 

>> 

# 

. . / network 2 

(Select Client B subnet) 

>> 

# 

sip 204.165.0.0 

(Assign source address for Client B) 

>> 

# 

mask 255.255.0.0 

(Assign the mask for Client B) 

>> 

# 

vipl <virtual server IP add of Site 4> 

(Select preferred Site 4) 

>> 

# 

vip2 <virtual server IP add of Site 2> 

(Select preferred Site 2) 


NOTE — For each client subnet, add only one static entry. 


Using this configuration, the DNS request “nortelnetworks.com” from 205.178.13.0 will get a 
DNS response with only the virtual server IP address of Site 1, if Site 1 has less load than 
Site 3. 
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Using Border Gateway Protocol for GSLB 


Border Gateway Protocol (BGP)-based GSLB utilizes the Internet’s routing protocols to local¬ 
ize content delivery to the most efficient and consistent site. It does so by using a shared IP 
block that co-exists in each Internet Service Provider’s (ISP’s) network and is then advertised, 
using BGP, throughout the Internet. 

Because of the way IP routing works, BGP-based GSLB allows for the routing protocols to 
route DNS requests to the closest location, which then returns IP addresses of that particular 
site, locking in the requests to that site. In effect, the Internet is making the decision of the best 
location for you, avoiding the need for advanced GSLB. 

Some corporations use more than one ISP as a way to increase the reliability and bandwidth of 
their Internet connection. Enterprises with more than one ISP are referred to as being multi¬ 
homed. Instead of multi-homing a network to several other networks, BGP-based GSLB 
enables you to multi-home a particular piece of content (DNS information) to the Internet by 
distributing the IP blocks that contain that content to several sites. 

When using DNS to select the site, a single packet is used to make the decision so that the 
request will not be split to different locations. Through the response to the DNS packet, a client 
is locked in to a particular site, resulting in efficient, consistent service that cannot be achieved 
when the content itself is shared. 

For example, in multi-homing, you can connect a data center to three different Internet provid¬ 
ers and have one DNS server that has the IP address 1.1.1.1. In this case, all requests can be 
received via any given feed but are funneled to the same server on the local network. In BGP- 
based GSLB, the DNS server (with the IP address 1.1.1.1) is duplicated and placed local to the 
peering point instead of having a local network direct traffic to one server. 

When a particular DNS server receives a request for a record (in this case, the Web switch), it 
returns with the IP address of a virtual server at the same site. This can be achieved using the 
local option (/cfg/slb/gslb/local ena) in the GSLB configuration. If one site is 
saturated, then the switch will failover and deliver the IP address of a more available site. 

For more information on configuring your switch to support BGP routing, see “Border Gate¬ 
way Protocol (BGP)” on page 32. 
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Chapter 13 

Firewall Load Balancing 


Firewall Load Balancing (FWLB) with Alteon Web switches allows multiple active firewalls 
to operate in parallel. Parallel operation allows users to maximize firewall productivity, scale 
firewall performance without forklift upgrades, and eliminate the firewall as a single point-of- 
failure. 

This chapter presents the following material: 

■ “Firewall Overview” on page 230 

An overview of firewalls and the various FWLB solutions supported by Alteon Web 
switches. 

■ “Basic FWLB” on page 232 

Explanation and example configuration for FWLB in simple networks, using two parallel 
firewalls and two Web switches. The basic FWLB method combines redirection filters and 
static routing for FWLB. 

■ “Four-Subnet FWLB” on page 241 

Explanation and example configuration for FWLB in a large-scale, high-availability net¬ 
work with redundant firewalls and Web switches. This method combines redirection fil¬ 
ters, static routing, and Virtual Router Redundancy Protocol (VRRP). 

■ “Advanced FWLB Concepts” on page 260 

□ “Free-Metric FWLB” on page 260. Using other load balancing metrics (besides 
hash) by enabling the Return to Sender (RTS) option. 

□ “Adding a Demilitarized Zone (DMZ)” on page 263. Adding a DMZ for servers that 
attach to the Web switch between the Internet and the firewalls. 

□ “Firewall Health Checks” on page 265. Methods for fine-tuning the health checks 
performed for FWLB. 
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Firewall Overview 


Firewall devices have become indispensable for protecting network resources from unautho¬ 
rized access. Prior to FWLB, however, firewalls could become critical bottlenecks or single 
points-of-failure for your network. 


As an example, consider the following network: 

"Dirty" Public Network 


Internet 


Firewall 

"Clean" Private Network 

ftsrS 


5lT! 

Private 

■hS 

Network 


DMZ 


Figure 13-1 Typical Firewall Configuration Before FWLB 

One network interface card on the firewall is connected to the public side of the network, often 
to an Internet router. This is known as the dirty or untrusted side of the firewall. Another net¬ 
work interface card on the firewall is connected to the side of the network with the resources 
that must be protected. This is known as the clean or trusted side of the firewall. 

In this simple example, all traffic passing between the dirty, clean, and DMZ networks must 
traverse the firewall, which examines each individual packet. The firewall is configured with a 
detailed set of rules that determine which types of traffic are allowed and which types are 
denied. Heavy traffic can turn the firewall into a serious bottleneck. The firewall is also a sin¬ 
gle point-of-failure device. If it goes out of service, external clients can no longer reach your 
services and internal clients can no longer reach the Internet. 

Sometimes, a Demilitarized Zone (DMZ) is attached to the firewall or between the Internet and 
the firewall. Typically, a DMZ contains its own servers that provide dirty-side clients with 
access to services, making it unnecessary for dirty-side traffic to use clean-side resources. 

FWLB with Alteon Web switches provides a variety of options that enhance firewall perfor¬ 
mance and resolve typical firewall problems. 
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Alteon Web switches support the following methods of FWLB: 

■ Basic FWLB for simple networks 

This method uses a combination of static routes and redirection filters and is usually 
employed in smaller networks. 

A Web switch filter on the dirty-side splits incoming traffic into streams headed for differ¬ 
ent firewalls. To ensure persistence of session traffic through the same firewall, distribu¬ 
tion is based on a mathematical hash of the IP source and destination addresses. 

For more information about basic FWLB, see “Basic FWLB” on page 232. 

■ Four-Subnet FWLB for larger networks 

Although similar to basic FWLB, the four-subnet method is more often deployed in larger 
networks that require high-availability solutions. This method adds Virtual Router Redun¬ 
dancy Protocol (VRRP) to the configuration. 

Just as with the basic method, four-subnet FWLB uses the hash metric to distribute fire¬ 
wall traffic and maintain persistence. 

For more information, see “Four-Subnet FWLB” on page 241. 

Each method is described in more detail in the following sections. 
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Basic FWLB 


The basic FWLB method uses a combination of static routes and redirection filters to allow 
multiple active firewalls to operate in parallel. 


Figure 13-2 shows a basic FWLB topology: 



Figure 13-2 Basic FWLB Topology 

The firewalls being load balanced are in the middle of the network, separating the dirty side 
from the clean side. This configuration requires a minimum of two Web switches: one on the 
dirty side of the firewalls and one on the clean side. 

A redirection filter on the dirty-side Web switch splits incoming client traffic into multiple 
streams. Each stream is routed through a different firewall. The valid client traffic in each 
stream is forwarded to a virtual server on the clean-side Web switch. The clean-side Web 
switch uses Server Load Balancing (SLB) settings to select a real server on the internal net¬ 
work for each incoming request. The same process is used for outbound server responses; a 
redirection filter on the clean-side Web switch splits the traffic, and static routes forward each 
stream through a different firewall and then back to the client. 

Although other metrics can be used in some configurations (see “Free-Metric FWLB” on page 
260), the distribution of traffic within each stream is normally based on a mathematical hash of 
the IP source and destination addresses. This ensures that each client request and its related 
responses will use the same firewall (a feature known as persistence ) and that the streams will 
be roughly equal in traffic load. 

Although basic firewall load-balancing techniques can support more firewalls as well as multi¬ 
ple switches on the clean and dirty sides for redundancy, the configuration complexity 
increases dramatically. The four-subnet FWLB solution is usually preferred in larger scale, 
high-availability topologies (see page 241). 
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Basic FWLB Implementation 

In this example, traffic is load balanced among the available firewalls. 


Client 




Internet 


1. Client sends a request 

2. Redir filter selects upper or lower path 

3. Static route directs request through 
the selected firewall 

4. Firewall forwards valid traffic 

5. SLB selects an available server 

6. Server responds 



7. Redir filter selects reverse path 

8. Static route directs response back 
through the same firewall 

9. Firewall forwards valid traffic 
10. Client receives response 


Figure 13-3 Basic FWLB Process 


1. The client requests data. 

The external clients intend to connect to services at the publicly advertised IP address assigned 
to a virtual server on the clean-side Web switch. 

2. A redirection filter balances incoming requests among different IP addresses. 

When the client request arrives at the dirty-side Web switch, a filter redirects it to a real server 
group that consists of a number of different IP addresses. This redirection filter splits the traffic 
into balanced streams: one for each IP address in the real server group. For FWLB, each IP 
address in the real server group represents an IP Interface (IF) on a different subnet on the 
clean-side Web switch. 

3. Requests are routed to the firewalls. 

On the dirty-side switch, one static route is needed for each traffic stream. For instance, the first 
static route will lead to an IP interface on the clean-side Web switch using the first firewall as 
the next hop. A second static route will lead to a second clean-side IP interface using the second 
firewall as the next hop, and so on. By combining the redirection filter and static routes, traffic 
is load balanced among all active firewalls. 


NOTE — More than one stream can be routed though a particular firewall. You can weight the 
load to favor one firewall by increasing the number of static routes that traverse it. 


All traffic between specific IP source/destination address pairs flows through the same fire¬ 
wall, ensuring that sessions established by the firewalls persist for their duration. 


Alteon Systems 

050159A, May 2001 


Chapter 13: Firewall Load Balancing ■ 233 













Web OS 9.0 Application Guide 


4. The firewalls decide if they should allow the packets and, if so, forwards them to a virtual 
server on the clean-side Web switch. 

Client requests are forwarded or discarded according to rules configured for each firewall. 


NOTE — Rule sets must be consistent across all firewalls. 


5. The clean-side Web switch performs normal SLB functions. 

Packets forwarded from the firewalls are sent to the original destination address, that is, the vir¬ 
tual server on the clean-side Web switch. There, they are load balanced to the real servers using 
standard SLB configuration. 

6. The real server responds to the client request. 

7. Redirection filters on the clean-side Web switch balance responses among different IP 
addresses. 

Redirection filters are needed on all ports on the clean-side Web switch that attach to real serv¬ 
ers or internal clients on the clean-side of the network. Filters on these ports redirect the Inter- 
net-bound traffic to a real server group that consists of a number of different IP addresses. Each 
IP address represents an IP interface on a different subnet on the dirty-side Web switch. 

8. Outbound traffic is routed to the firewalls. 

Static routes are configured on the clean-side switch. One static route is needed for each stream 
that was configured on the dirty-side Web switch. For instance, the first static route would be 
configured to lead to the first dirty-side IP interface using the first firewall as the next hop. The 
second static route would lead to the second dirty-side IP interface using the second firewall as 
the next hop, and so on. 

Since Web switches intelligently maintain state information, all traffic between specific IP 
source/destination addresses flows through the same firewall, maintaining session persistence. 


NOTE — If Network Address Translation (NAT) software is used on the firewalls, FWLB ses¬ 
sion persistence requires the RTS option to be enabled on the Web switch (see “Free-Metric 
FWLB” on page 260). 


9. The firewall decides if it should allow the packet and, if so, forwards it to the dirty-side 
Web switch. 

Each firewall forwards or discards the server responses according to the rules that are config¬ 
ured for it. Forwarded packets are sent to the dirty-side Web switch and out to the Internet. 

10. The client receives the server response. 
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Configuring Basic FWLB 

The steps for configuring basic FWLB are provided below. While two or four switches can be 
used, the following procedure assumes a simple network topology with only two Web switches 
(one on each side of the firewalls) as shown in Figure 13-4. 



Figure 13-4 Basic FWLB Example Network 


Configure the Dirty-Side Web Switch 

1. Configure VLANs. 


NOTE — Alternately, if using hubs between the switches and firewalls and you do not wish to 
configure VLANs, you must enable Spanning Tree Protocol to prevent broadcast loops. 


2. Define the dirty-side IP interface. 

In addition to one IP interface for general switch management, there must be one dirty-side IP 
interface for each firewall path being load balanced. Each must be on a different subnet. 


>> 

# 

/cfg/ip/if 

1 


(Select IP interface 1) 

>> 

IP 

Interface 

1# 

addr 192.16.12.1 

(Set address for switch management) 

>> 

IP 

Interface 

1# 

mask 255.255.255.0 

(Set subnet mask for inteiface 1) 

>> 

IP 

Interface 

1# 

ena 

(Enable IP interface 1) 

>> 

IP 

Interface 

1# 

../if 2 

(Select IP interface 2) 

>> 

IP 

Interface 

2# 

addr 10.1.1.1 

(Set the IP address for interface 2) 

>> 

IP 

Interface 

2# 

mask 255.255.255.0 

(Set subnet mask for interface 2) 

>> 

IP 

Interface 

2# 

ena 

(Enable IP interface 2) 

>> 

IP 

Interface 

2# 

../if 3 

(Select IP interface 3) 

>> 

IP 

Interface 

3# 

addr 10.1.2.1 

(Set the IP address for interface 3) 

>> 

IP 

Interface 

3# 

mask 255.255.255.0 

(Set subnet mask for interface 3) 

>> 

IP 

Interface 

3# 

ena 

(Enable IP interface 3) 


Alteon ((^Systems 

050159A, May 2001 


Chapter 13: Firewall Load Balancing ■ 235 











Web OS 9.0 Application Guide 


3. Configure the clean-side IP interface as if they were real servers on the dirty side. 

Later in this procedure, you’ll configure one clean-side IP interface on a different subnet for 
each firewall path being load balanced. On the dirty-side Web switch, create two real servers 
using the IP address of each clean-side IP interface used for FWLB. 


>> 

IP Interface 

3# 

/cfg/slb/real 1 

(Select real server 1) 

>> 

Real 

server 

1# 

rip 10.1.3.1 

(Assign clean-side IF 2 address) 

>> 

Real 

server 

1# 

ena 

(Enable real server 1) 

>> 

Real 

server 

1# 

../real 2 

(Select real server 2) 

>> 

Real 

server 

2# 

rip 10.1.4.1 

(Assign clean-side IF 3 address) 

>> 

Real 

server 

2# 

ena 

(Enable real server 1) 


NOTE — Each of the four IFs used for FWLB (two on each Web switch) in this example must 
be configured for a different IP subnet. 


4. Place the IP interface real servers into a real server group. 


>> Real server 2# /cfg/slb/group 1 (Select real server group 1) 

» Real server group 1# add 1 (Add real server 1 to group 1) 

» Real server group 1# add 2 (Add real server 2 to group 1) 


5. Set the health check type for the real server group to ICMP. 


>> Real server group 1# health icmp (Select ICMP as health check type) 


6. Set the load-balancing metric for the real server group to hash. 


>> Real server group 1# metric hash (Select SLB hash metric for group 1) 


Using the hash metric, all traffic between specific IP source/destination address pairs flows 
through the same firewall. This ensures that sessions established by the firewalls are main¬ 
tained for their duration. 


NOTE — Other load balancing metrics such as leastconns, roundrobin, minmiss, 
response, and bandwidth can be used when enabling the Return to Sender (RTS) option. 
For more information, see “Free-Metric FWLB” on page 260. 


7. Enable SLB on the switch. 


>> Real server group 1# /cfg/slb/on 
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8. Create a filter to allow local subnet traffic on the dirty side of the firewalls to reach the 
firewall interfaces. 


>> 

Layer 

4# /cfg/slb/filt 10 

(Select filter 10) 

>> 

Filter 

10# sip any 

(From any source IP address) 

>> 

Filter 

10# dip 192.16.12.0 

(To this destination IP address) 

>> 

Filter 

10# action allow 

(Allow frames with this DIP address) 

>> 

Filter 

10# ena 

(Enable filter) 


9. Create the FWLB redirection filter. 

This filter will redirect inbound traffic, load balancing it among the defined real servers in the 
group. In this network, the real servers represent IP interfaces on the clean-side Web switch. 


» 

Filter 

10# 

.,/filt 15 

(Select filter 15) 

» 

Filter 

15# 

sip any 

(From any source IP address) 

» 

Filter 

15# 

dip any 

(To any destination IP address) 

» 

Filter 

15# 

proto any 

(For any protocol) 

» 

Filter 

15# 

action redir 

(Perform redirection) 

» 

Filter 

15# 

group 1 

(To real server group 1) 

» 

Filter 

15# 

ena 

(Enable the filter) 


10. Add filters to the ingress port. 


» 

Filter 15# 

./port 1 

(Select the ingress port) 

» 

SLB 

Port 

1# 

add 10 

(Add the filter to the ingress port) 

» 

SLB 

Port 

1# 

add 15 

(Add the filter to the ingress port) 

» 

SLB 

Port 

1# 

filt ena 

(Enable filtering on the port) 


11. Define static routes to the clean-side IP interfaces, using the firewalls as gateways. 

One static route is required for each firewall path being load balanced. In this case, two paths 
are required: one that leads to clean-side IF 2 (10.1.3.1) through the first firewall (10.1.1.10) as 
its gateway, and one that leads to clean-side IF 3 (10.1.4.1) through the second firewall 
(10.1.2.10) as its gateway. 


>> SLB Port 5# /cfg/ip/route 

» IP Static Route# add 10.1.3.1 255.255.255.255 10.1.1.10 
>> IP Static Route# add 10.1.4.1 255.255.255.255 10.1.2.10 


12. Apply and save the configuration changes. 


» # apply 
» # save 
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Configure the Clean-Side Web Switch 

1. Define the clean-side IP interfaces. 

Create one clean-side IP interface on a different subnet for each firewall being load balanced. 


NOTE — An extra IP interface (IF 1) prevents server-to-server traffic from being redirected. 


>> 

# 

/cfg/ip/if 

1 


(Select IP interface 1) 

>> 

IP 

Interface 

1# 

addr 20.1.1.1 

(Set the IP address for interface 1) 

>> 

IP 

Interface 

1# 

mask 255.255.255.0 

(Set subnet mask for interface 1) 

>> 

IP 

Interface 

1# 

ena 

(Enable IP interface 1) 

>> 

IP 

Interface 

1# 

../if 2 

(Select IP interface 2) 

>> 

IP 

Interface 

2# 

addr 10.1.3.1 

(Set the IP address for interface 2) 

>> 

IP 

Interface 

2# 

mask 255.255.255.0 

(Set subnet mask for interface 2) 

>> 

IP 

Interface 

2# 

ena 

(Enable IP interface 2) 

>> 

IP 

Interface 

2# 

../if 3 

(Select IP interface 3) 

>> 

IP 

Interface 

3# 

addr 10.1.4.1 

(Set the IP address for interface 3) 

>> 

IP 

Interface 

3# 

mask 255.255.255.0 

(Set subnet mask for interface 3) 

>> 

IP 

Interface 

3# 

ena 

(Enable IP interface 3) 


2. Configure the dirty-side IP interfaces as if they were real servers on the clean side. 

You should already have configured a dirty-side IP interface on a different subnet for each fire¬ 
wall path being load balanced. Create two real servers on the clean-side switch, using the IP 
address of each dirty-side IP interface. 


» 

IP Interface 

5# 

/cfg/slb/real 1 

(Select real server I) 

» 

Real 

server 

1# 

rip 10.1.1.1 

(Assign dirty-side IF 1 address) 

» 

Real 

server 

1# 

ena 

(Enable real server 1) 

» 

Real 

server 

1# 

../real 2 

(Select real server 2) 

» 

Real 

server 

2# 

rip 10.1.2.1 

(Assign dirty-side IF 2 address) 

» 

Real 

server 

2# 

ena 

(Enable real server 2) 


NOTE — Each of the four IP interfaces (two on each Web switch) in this example must be con¬ 
figured for a different IP subnet. 


3. Place the real servers into a real server group. 


» 

Real 

server 

2# ../group 1 

(Select real sen’er group 1) 

» 

Real 

server 

group 1# add 1 

(Select real sen’er 1 to group 1) 

» 

Real 

server 

group 1# add 2 

(Select real sen’er 2 to group 1) 
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4. Set the health check type for the real server group to ICMP. 


>> Real server group 1# health icmp (Select ICMP as health check type) 


5. Set the load-balancing metric for the real server group to hash. 


» Real server group 1# metric hash (Select SLB hash metric for group 1) 


NOTE — The clean-side Web switch must use the same metric as defined on the dirty side. 


6. Enable server load balancing on the switch. 


>> Real server group 1# /cfg/slb/on 


7. Create a filter to prevent server-to-server traffic from being redirected. 


>> 

Layer 

4# /cfg/slb/filt 10 

(Select filter 10) 

>> 

Filter 

10# sip any 

(From any source IP address) 

>> 

Filter 

10# dip 20.1.1.0 

(To base IP address for IF 5) 

>> 

Filter 

10# dmask 255.255.255.0 

(For the range of addresses) 

>> 

Filter 

10# proto any 

(For any protocol) 

>> 

Filter 

10# action allow 

(Allow traffic) 

>> 

Filter 

10# ena 

(Enable the filter) 


8. Create the redirection filter. 

This filter will redirect outbound traffic, load balancing it among the defined real servers in the 
group. In this case, the real servers represent IP interfaces on the dirty-side switch. 


» 

Filter 

10# 

.,/filt 15 

(Select filter 15) 

» 

Filter 

15# 

sip any 

(From any source IP address) 

» 

Filter 

15# 

dip any 

(To any destination IP address) 

» 

Filter 

15# 

proto any 

(For any protocol) 

» 

Filter 

15# 

action redir 

(Perform redirection) 

» 

Filter 

15# 

group 1 

(To real server group 1) 

» 

Filter 

15# 

ena 

(Enable the filter) 
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9. Add the filters to the ingress ports for the outbound packets. 

Redirection filters are needed on all the ingress ports on the clean-side Web switch. Ingress 
ports are any that attach to real servers or internal clients on the clean-side of the network. In 
this case, two real servers are attached to the clean-side Web switch on port 4 and port 5. 


>> 

Filter 15# 

./port 4 

(Select ingress port 4) 

>> 

SLB 

Port 

4# 

add 10 

(Add the filter to the ingress port) 

>> 

SLB 

Port 

4# 

add 15 

(Add the filter to the ingress port) 

>> 

SLB 

Port 

4# 

filt ena 

(Enable filtering on the port) 

>> 

SLB 

Port 

4# 

../port 5 

(Select ingress port 5) 

>> 

SLB 

Port 

5# 

add 10 

(Add the filter to the ingress port) 

>> 

SLB 

Port 

5# 

add 15 

(Add the filter to the ingress port) 

>> 

SLB 

Port 

5# 

filt ena 

(Enable filtering on the port) 


10. Define static routes to the dirty-side IP interfaces, using the firewalls as gateways. 

One static route is required for each firewall path being load balanced. In this case, two paths 
are required: one that leads to dirty-side IF 2 (10.1.1.1) through the first firewall (10.1.3.10) as 
its gateway, and one that leads to dirty-side IF 3 (10.1.2.1) through the second firewall 
(10.1.4.10) as its gateway. 


>> SLB Port 5# /cfg/ip/route 

» IP Static Route# add 10.1.1.1 255.255.255.255 10.1.3.10 
» IP Static Route# add 10.1.2.1 255.255.255.255 10.1.4.10 


NOTE — Configuring static routes for FWLB does not require IP forwarding to be turned on. 


11. Apply and save the configuration changes. 


>> # apply 
>> # save 
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Four-Subnet FWLB 


The four-subnet FWLB method is often deployed in large networks that require high-availabil¬ 
ity solutions. This method uses filtering, static routing, and Virtual Router Redundancy Proto¬ 
col (VRRP) to provide parallel firewall operation between redundant Web switches. 


Figure 13-5 shows one possible network topology using the four-subnet method: 


Dirty Side 


Subnet 2 


Clean Side 

Subnet 3 | Subnet 4 


Primary 


Subnet 1 


Primary 


Internet 



Routers 


Simple 

Switches 


Secondary 
Web Switch 


Firewalls 


Secondary 
Web Switch 


Servers 


Figure 13-5 Four-Subnet FWLB Topology 


This network is classified as a high-availability network because no single component or link 
failure could cause network resources to become unavailable. Simple switches and vertical 
block interswitch connections are used to provide multiple paths for network failover. Often, 
the interswitch links between the primary and secondary Web switches are trunked together 
with multiple ports for additional protection from failure. 


NOTE — Other topologies that use internal hubs, or diagonal cross-connections between the 
Web switches and simple switches are also possible. However, while such topologies may 
resolve networking issues in special circumstances, they can make configuration more com¬ 
plex and can cause restrictions on the use of advanced features such as Active-Active VRRP, 
free-metric FWLB, or Content Intelligent Switching. Alternate topologies are explored in more 
detail in Alteon WebSystems FWLB white papers, but are not within the scope of this manual. 
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As shown in Figure 13-5, the network is divided into four sections: 

■ Subnet 1 includes all equipment between the exterior routers and dirty-side Web switches. 

■ Subnet 2 includes the dirty-side Web switches with their interswitch link, and dirty-side 
firewall interfaces. 

■ Subnet 3 includes the clean-side firewall interfaces, and clean-side Web switches with 
their interswitch link. 

■ Subnet 4 includes all equipment between the clean-side Web switches and their servers. 

In this network, external traffic arrives through both routers. Since VRRP is enabled, one of 
the dirty-side Web switches acts as primary and receives all traffic. The dirty-side primary Web 
switch performs FWLB in a fashion similar to basic FWLB: a redirection filter splits traffic 
into multiple streams which are routed through the available firewalls to the primary clean-side 
Web switch. 

Just as with the basic method, four-subnet FWLB uses the hash metric to distribute firewall 
traffic and maintain persistence, though other load-balancing metrics can be used by configur¬ 
ing an additional Return to Sender (RTS) option (see “Free-Metric FWLB” on page 260). 


Four-Subnet FWLB Implementation 


In this example, traffic between the redundant Web switches is load balanced among the avail¬ 
able firewalls. 


Dirty Side 


Clean Side 


Subnet 1 


Subnet 2 


Subnet 3 


Subnet 4 


Primary 


Primary 


Intern* 



1. VRRP forces incomming traffic to converge on primary dirty-side Web switch 

2. Firewall load balancing occurs between primary Web switches 

3. Primary clean-side Web switch performs standard SLB 


Figure 13-6 Four-Subnet FWLB Process 
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1. Incoming traffic converges on the primary dirty-side Web switch. 

External traffic arrives through redundant routers. A set of interconnected switches ensures 
that both routers have a path to each dirty-side Web switch. 

VRRP is configured on each dirty-side Web switch so that one acts as the primary routing 
switch. If the primary fails, the secondary takes over. 

2. FWLB is performed between primary Web switches. 

Just as with basic FWLB, filters on the dirty-side Web switch ingress ports redirect traffic to a 
real server group comprised of multiple IP addresses. This splits incoming traffic into multiple 
streams. Each stream is then routed toward the primary clean-side Web switch through a differ¬ 
ent firewall. 

Although other load balancing metrics can be used in some configurations (see “Free-Metric 
FWLB” on page 260), the distribution of traffic within each stream is normally based on a 
mathematical hash of the IP source and destination addresses. This ensures that each request 
and its related responses will use the same firewall (a feature known as persistence) and that 
the streams will be statistically equal in traffic load. 

3. The primary Web switch forwards the traffic to its destination. 

Once traffic arrives at the primary clean-side Web switch, it is forwarded to its destination. In 
this example, the Web switch uses regular server load balancing settings to select a real server 
on the internal network for each incoming request. 

The same process is used for outbound server responses; a filter on the clean-side Web switch 
splits the traffic, and static routes forward each response stream back through the same firewall 
that forwarded the original request. 
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Configuring Four-Subnet FWLB 

An example network for four-subnet FWLB is illustrated in Figure 13-7. While other complex 
topologies are possible, this example assumes a high-availability network using block (rather 
than diagonal) interconnections between switches. 


Dirty Side 

Clean Side 

Subnet 1 (VLAN 1): 
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Router 
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Web Switch #2 
IF1:195.1.1.11 
IF2:10.10.2.11 
IF3:10.10.2.12/32 


Firewall #2 
Dirty: 10.10.2.4 
Clean: 10.10.3.4 


Web Switch #4 
IF1:10.10.4.11 
IF2:10.10.3.11 
IF3:10.10.3.12/32 
VIP: 10.10.4.100 



10.10.4.21 


10.10.4.22 


Figure 13-7 Four-Subnet FWLB Example Network 


NOTE — The port designations of both dirty-side Web switches are identical, as are the port 
designations of both clean-side Web switches. This simplifies configuration by allowing you to 
synchronize each primary Web switch’s configuration with the secondary. 


Four-subnet FWLB configuration is summarized as follows: 


■ Configure routers and firewalls and test them for proper operation. 

■ Configure VLANs, IP interfaces, and static routes on all Web switches and test them. 

■ Configure secondary web switches with VRRP support settings. 

■ Configure FWLB groups and redirection filters on the primary dirty-side Web switch. 

■ Configure and synchronize VRRP on the primary dirty-side Web switch. 

■ Configure FWLB and SLB groups, and add FWLB redirection filters on the primary 
clean-side Web switch. 

■ Configure VRRP on the primary clean-side Web switch and synchronize the secondary. 
These steps are explained in detail in the following sections. 
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Configure the Routers 

The routers must be configured with a static route to the destination services being accessed by 
the external clients. 

In this example, the external clients intend to connect to services at a publicly advertised IP 
address on this network. Since the real servers are load balanced behind a virtual server on the 
clean-side Web switch using normal SLB settings, the routers need a static route to the virtual 
server IP address. The next hop for this static route is the Web switch Virtual Interface Router 
(VIR) which is in the same subnet as the routers: 

Route Added: 10.10.4.100 (to clean-side virtual server) via 195.1.1.9 (Subnet 1 VIR) 

Configure the Firewalls 

Before you configure the Web switches, the firewalls must be properly configured. For incom¬ 
ing traffic, each firewall must be configured with a static route to the clean-side virtual server, 
using the VIR in its clean-side subnet as the next hop. For outbound traffic, each firewall must 
use the VIR in its dirty-side subnet as the default gateway. 

In this example, the firewalls are configured with the following IP addresses: 


Table 2 Four-Subnet Firewall IP Address Configuration 


Item 

Address 

Firewall 1 

Dirty-side IP interface 
Clean-side IP interface 
Default Gateway 

Route Added 

10.10.2.3 

10.10.3.3 

10.10.2.9 (Subnet 2 VIR) 

10.10.4.100 (virtual server) via 10.10.3.9 (Subnet 3 VIR) 

Firewall 2 

Dirty-side IP interface 
Clean-side IP interface 
Default Gateway 

Route Added 

10.10.2.4 

10.10.3.4 

10.10.2.9 (dirty-side VIR) 

10.10.4.100 (virtual server) via 10.10.3.9 (Subnet 3 VIR) 

The firewalls must also be configured with rules that determine which types of traffic will be 
forwarded through the firewall and which will be dropped. All firewalls participating in FWLB 
must be configured with the same set of rules. 

NOTE — It is important to test the behavior of the firewalls prior to adding FWLB. 
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Configure Connectivity for the Primary Dirty-Side Web Switch 

1. Configure VLANs on the primary dirty-side Web switch. 

Two VLANs are required. VLAN 1 includes the port that attaches to the Internet. VLAN 2 
includes the firewall port and interswitch connection port. 


>> # ../vlan 2 
>> # add 2 
>> # add 9 
>> # ena 


NOTE — Port 1 is part of VLAN 1 by default and is not required to be manually configured. 


2. Configure IP interfaces on the primary dirty-side Web switch. 

Three IP interfaces are used. IF 1 is on placed on Subnet 1. IF 2 will be used whenever routing 
traffic through the top firewall. IF 3 will be used whenever routing through the lower firewall. 
To avoid confusion, IF 2 and IF 3 will be used in the same way on all Web switches. 



NOTE — By configuring the IP interface mask prior to the IP address, the broadcast address is 
automatically calculated. Also, only the first IP interface in a given subnet is given the full sub¬ 
net range mask. Subsequent IP interfaces (such as IF 3) are given individual masks. 


3. Turn Spanning Tree Protocol (STP) off for the primary dirty-side Web switch. 


>> # /cfg/stp/off 
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4. Configure static routes on the primary dirty-side Web switch. 

Four static routes are needed: 

■ To primary clean-side IF 2 via Firewall 1 using dirty-side IF 2 

■ To primary clean-side IF 3 via Firewall 2 using dirty-side IF 3 

■ To secondary clean-side IF 2 via Firewall 1 using dirty-side IF 2 

■ To secondary clean-side IF 3 via Firewall 2 using dirty-side IF 3 


NOTE — Remember, IF 2 is being used on all Web switches whenever routing through the top 
firewall, and IF 3 is being used on all Web switches whenever routing through the lower fire¬ 
wall. 


The static route add command uses the following format: 

add <i destination address> <dest. mask> <gateway address> <source interface> 
This example requires the following static route configuration: 


>> # /cfg/ip/frwd/route 

» # add 10.10.3.1 255.255.255.255 10.10.2.3 2 
» # add 10.10.3.2 255.255.255.255 10.10.2.4 3 
>> # add 10.10.3.11 255.255.255.255 10.10.2.3 2 
» # add 10.10.3.12 255.255.255.255 10.10.2.4 3 


NOTE — When defining static routes for FWLB, it is important to specify the source IP inter¬ 
face numbers. 


5. Make your changes take effect. 


» # apply 
» # save 
» # /boot/reset 
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Configure Connectivity for the Secondary Dirty-Side Web Switch 

Except for the IP interfaces, this configuration is identical to the primary dirty-side Web switch. 

1. Configure VLANs on the secondary dirty-side Web switch. 


>> # /cfg/vlan 2 
>> # add 2 
>> # add 9 
>> # ena 


2. Configure IP interfaces on the primary dirty-side Web switch. 



3. Turn STP off for the primary dirty-side Web switch. 


>> # /cfg/stp/off 


4. Configure static routes on the primary dirty-side Web switch. 


>> # /cfg/ip/frwd/route 

>> # add 10.10.3.1 255.255.255.255 10.10.2.3 2 
» # add 10.10.3.2 255.255.255.255 10.10.2.4 3 
>> # add 10.10.3.11 255.255.255.255 10.10.2.3 2 
>> # add 10.10.3.12 255.255.255.255 10.10.2.4 3 


5. Make your changes take effect. 


>> # apply 

>> # save 

>> # /boot/reset 
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Configure Connectivity for the Primary Clean-Side Web Switch 

1. Configure VLANs on the primary clean-side Web switch. 

Two VLANs are required. VLAN 3 includes the firewall port and interswitch connection port. 
VLAN 4 includes the port that attaches to the real servers. 


>> 

# 

/cfg/vlan 3 

>> 

# 

add 3 

>> 

# 

add 9 

>> 

# 

ena 

>> 

# 

../vlan 4 

>> 

# 

add 4 

>> 

# 

ena 


2. Configure IP interfaces on the primary clean-side Web switch. 



3. Turn STP off for the primary clean-side Web switch. 


» # /cfg/stp/off 
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4. Configure static routes on the primary clean-side Web switch. 

Four static routes are needed: 

■ To primary dirty-side IF 2 via Firewall 1 using clean-side IF 2 

■ To primary dirty-side IF 3 via Firewall 2 using clean-side IF 3 

■ To secondary dirty-side IF 2 via Firewall 1 using clean-side IF 2 

■ To secondary dirty-side IF 3 via Firewall 2 using clean-side IF 3 

Again, the static route add command uses the following format: 

add <destination address> <dest. mask> <gateway address> <source interface> 
This example requires the following static route configuration: 


>> # /cfg/ip/frwd/route 

» # add 10.10.2.1 255.255.255.255 10.10.3.3 2 
» # add 10.10.2.2 255.255.255.255 10.10.3.4 3 
>> # add 10.10.2.11 255.255.255.255 10.10.3.3 2 
>> # add 10.10.2.12 255.255.255.255 10.10.3.4 3 


5. Make your changes take effect. 


>> # apply 

>> # save 

>> # /boot/reset 


Configure Connectivity for the Secondary Clean-Side Web Switch 

1. Configure VLANs on the secondary clean-side Web switch. 


>> 

# 

/cfg/vlan 3 

>> 

# 

add 3 

>> 

# 

add 9 

>> 

# 

ena 

>> 

# 

../vlan 4 

>> 

# 

add 4 

>> 

# 

ena 
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2. Configure IP interfaces on the secondary clean-side Web switch. 



3. Turn STP off for the secondary clean-side Web switch. 


>> # /cfg/stp/off 


4. Configure static routes on the secondary clean-side Web switch. 


» # /cfg/ip/frwd/route 

» # add 10.10.2.1 255.255.255.255 10.10.3.3 2 
» # add 10.10.2.2 255.255.255.255 10.10.3.4 3 
>> # add 10.10.2.11 255.255.255.255 10.10.3.3 2 
>> # add 10.10.2.12 255.255.255.255 10.10.3.4 3 


5. Make your changes take effect. 


» # apply 
» # save 
» # /boot/reset 
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Verify Proper Connectivity 

To verify proper configuration up to this point, use the ping option to test network connectiv¬ 
ity. At each Web switch, you should receive a valid response when pinging the destination 
addresses established in the static routes. 

For example, on the secondary clean-side Web switch, the following commands should receive 
a valid response: 



Configure VRRP Support on the Secondary Dirty-Side Web Switch 

The secondary dirty-side Web switch must be configured with the primary as its peer. Once 
this is done, the secondary will get the remainder of its configuration from the primary when 
synchronized in a later step. 


In this example, the secondary is configured to use primary dirty-side IF 1 as its peer. 


>> 

# 

/cfg/vrrp/on 

>> 

# 

/cfg/slb 

>> 

# 

on 

>> 

# 

sync/peer 1 

>> 

# 

addr 195.1.1.10 

>> 

# 

ena 

>> 

# 

apply 

>> 

# 

save 


Configure VRRP Support on the Secondary Clean-Side Web Switch 


In this example, the secondary Web switch uses primary clean-side IF 1 as its peer. 


>> 

# 

/cfg/vrrp/on 

>> 

# 

/cfg/slb 

>> 

# 

on 

>> 

# 

sync/peer 1 

>> 

# 

addr 10.10.4.10 

>> 

# 

ena 

>> 

# 

apply 

>> 

# 

save 
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Complete the Configuration of the Primary Dirty-Side Web Switch 

1. Create an FWLB real server group on the primary dirty-side Web switch. 

A real server group is used as the target for the FWLB redirection filter. Each IP address 
assigned to the group represents a path through a different firewall. In this case, since two fire¬ 
walls are used, two addresses are added to the group. 

Earlier, it was stated that this example uses IF 2 on all Web switches whenever routing through 
the top firewall and IF 3 on all Web switches whenever routing through the lower firewall. 
Therefore, the first address will represent the primary clean-side IF 2, and the second repre¬ 
sents the primary clean-side IF 3. 


>> 

# 

/cfg/slb 

>> 

# 

on 

>> 

# 

real 1 

>> 

# 

rip 10.10.3.1 

>> 

# 

ena 

>> 

# 

../real 2 

>> 

# 

rip 10.10.3.2 

>> 

# 

ena 

>> 

# 

../group 1 

>> 

# 

add 1 

>> 

# 

add 2 

>> 

# 

metric hash 


Using the hash metric, all traffic between specific IP source/destination address pairs flows 
through the same firewall, ensuring that sessions established by the firewalls are maintained 
for their duration (persistence). 


NOTE — Other load balancing metrics, such as leastconns, roundrobin, minmiss, 
response, and bandwidth, can be used when enabling the Return to Sender (RTS) option. 
For more information, see “Free-Metric FWLB” on page 260. 
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2. Create the FWLB filters. 

Three filters are required on the port attaching to the routers: 

■ Filter 10 prevents local traffic from being redirected. 

■ Filter 20 prevents VRRP traffic from being redirected. 

■ Filter 224 redirects the remaining traffic to the firewall group. 
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3. Configure VRRP on the primary dirty-side Web switch. 

VRRP in this example requires two virtual routers-one for the subnet attached to the routers, 
and one for the subnet attached to the firewalls. 



4. Configure the VRRP peer on the primary dirty-side Web switch. 


>> # /cfg/slb/sync 
>> # prios d 
>> # peer 1 
» # ena 

» # addr 195.1.1.11 


5. Apply and save your configuration changes. 


>> # apply 
>> # save 


6. Synchronize primary and secondary dirty-side Web switches. 


» # /oper/slb/sync 
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Complete the Configuration of the Primary Clean-Side Web Switch 

1. Create an FWLB real server group on the primary clean-side Web switch. 

A real server group is used as the target for the FWLB redirection filter. Each IP address 
assigned to the group represents a path back through a different firewall. In this case, since two 
firewalls are used, two addresses are added to the group. 


NOTE — Remember that IF 2 is used on all Web switches whenever routing through the top 
firewall, and IF 3 is used on all Web switches whenever routing through the lower firewall. 


>> 

# 

/cfg/sib 

>> 

# 

on 

>> 

# 

real 1 

>> 

# 

rip 10.10.2.1 

>> 

# 

ena 

>> 

# 

. . /real 2 

>> 

# 

rip 10.10.2.2 

>> 

# 

ena 

>> 

# 

../group 1 

>> 

# 

add 1 

>> 

# 

add 2 

>> 

# 

metric hash 


NOTE — The clean-side Web switch must use the same metric as defined on the dirty side. For 
information on using metrics other than hash, see “Free-Metric FWLB” on page 260. 
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2. Create an SLB real server group on the primary clean-side Web switch (optional). 

The external clients intend to connect to HTTP services at a publicly advertised IP address. 
The servers on this network are load balanced by a virtual server on the clean-side Web switch. 
SLB options are configured as follows: 


>> 

# 

/cfg/slb 

>> 

# 

real 20 

>> 

# 

rip 10.10.4.20 

>> 

# 

ena 

>> 

# 

. ./real 21 

>> 

# 

rip 10.10.4.21 

>> 

# 

ena 

>> 

# 

../real 22 

>> 

# 

rip 10.10.4.22 

>> 

# 

ena 

>> 

# 

../group 2 

>> 

# 

add 20 

>> 

# 

add 21 

>> 

# 

add 22 

>> 

# 

metric leastconns 

>> 

# 

../virt 1 

>> 

# 

vip 195.2.1.1 

>> 

# 

service http 

>> 

# 

group 2 

>> 

# 

ena 

>> 

# 

../port 4/server ena 

>> 

# 

../port 3/client ena 

>> 

# 

../port 9/client ena 


NOTE — The virtual server IP address configured in this step will also be configured as a Vir¬ 
tual Server Router (VSR) when VRRP is configured in a later step. 


3. Create the FWLB filters on the primary clean-side Web switch. 

Three filters are required on the port attaching to the real servers: 

■ Filter 10 prevents local traffic from being redirected. 

■ Filter 20 prevents VRRP traffic from being redirected. 

■ Filter 224 redirects the remaining traffic to the firewall group. 
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4. Configure VRRP on the primary clean-side Web switch. 

VRRP in this example requires two virtual routers to be configured-one for the subnet attached 
to the real servers, and one for the subnet attached to the firewalls. 
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A third virtual router is required for the virtual server used for optional SLB. 



5. Configure the peer on the primary clean-side Web switch. 


» # /cfg/slb/sync 
» # prios d 
>> # peer 1 
>> # ena 

>> # addr 10.10.4.11 


6. Apply and save your configuration changes. 


» # apply 
» # save 


7. Synchronize primary and secondary dirty-side Web switches. 


>> # /oper/slb/sync 
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Advanced FWLB Concepts 


Free-Metric FWLB 

Free-metric FWLB allows to you use load-balancing metrics other than hash, such as 
leastconns, roundrobin, minmiss, response, and bandwidth for more versatile 
FWLB. 

The free-metric method uses the Return to Sender (RTS) option. RTS can be used with basic 
FWLB or four-subnet FWLB networks. 

Free-Metric with Basic FWLB 

For this example, review the basic FWLB example network. 



Figure 13-8 Basic FWLB Example Network 


To use free-metric FWLB in this network, the following configuration changes are necessary. 

1. On the clean-side Web switch, enable RTS on the ports attached to firewalls (ports 2 and 3). 


>> # /cfg/slb/port 2/rts enable 
>> # ../port 3/rts enable 


2. On the dirty-side Web switch, remove the redirection filter from the ports attached to the 
real servers (ports 4 and 5), but make sure filter processing is enabled. 


>> 

# 

../port 4/rem 

224 

>> 

# 

filt ena 


>> 

# 

../port 5/rem 

224 

>> 

# 

filt ena 
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3. On the dirty-side Web switch, set the FWLB metric. 


» # . . /group 1 
» # metric <metric tvpe> 


Any of the following load-balancing metrics can be used: hash, leastconns, roun- 
drobin, minmiss, response, and bandwidth. See “Metrics for Real Server Groups” 
on page 80 for details on using each metric. 


NOTE — Some metrics allow other options (such as weights) to be configured. 


Free-Metric with Four-Subnet FWLB 

For this example, review the four-subnet example network. 


Subnet 1 (VLAN 1): 
195.1.1.0/24 


Dirty Side 


Clean Side 


Subnet 2 (VLAN 2): 
10.10.2.0/24 


Subnet 3 (VLAN 3): 
10.10.3.0/24 


Subnet 4 (VLAN 4): 
10.10.4.0/24 


Web Switch #1 
IF1:195.1.1.10 
IF2:10.10.2.1 
IF3:10.10.2.2/32 



Web Switch #2 
IF1:195.1.1.11 
IF2:10.10.2.11 


Web Switch #3 
IF1:10.10.4.10 


Firewall #1 IF2:10.10.3.1 

Dirty: 10.10.2.3 IF3:10.10.3.2/32 

Clean: 10.10.3.3 VIP: 10.10.4.100 



i —mi ty . lu.iu.t.t u i. lu.iv.t. i i 

Clean: 10.10.3.4 IF2:10.10.3.11 


IF3:10.10.2.12/32 


IF3:10.10.3.12/32 
VIP: 10.10.4.100 


Figure 13-9 Four-Subnet FWLB Example Network 
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To use free-metric FWLB in this network, the following configuration changes are necessary. 

1. On the clean-side Web switches, enable RTS on the ports attached to the firewalls (port 3) 
and on the interswitch port (port 9). 

On both clean-side switches: 

>> # /cfg/slb/port 3/rts enable 
>> # ../port 9/rts enable 

2. On the clean-side Web switches, remove the redirection filter from the ports attached to 
the real servers (ports 4), but make sure filter processing is enabled. 

On both clean-side switches: 

>> # ../port 4/rem 224 
>> # filt ena 

3. On the dirty-side Web switches, set the FWLB metric. 

On both dirty-side Web switches: 


>> # ../group 1 

>> # metric oneiric typo 


Any of the following load-balancing metrics can be used: hash, leastconns, roun- 
drobin, minmiss, response, and bandwidth. See “Metrics for Real Server Groups” 
on page 80 for details on using each metric. 


NOTE — Some metrics allow other options (such as weights) to be configured. 
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Adding a Demilitarized Zone (DMZ) 


Implementing a DMZ in conjunction with firewall load balancing enables the Web switch to 
do the traffic filtering, off-loading this task from the firewall. A DMZ is created by configuring 
FWLB with another real server group and a redirection filter towards the DMZ subnets. 

The DMZ servers can be connected to the Web switch on the dirty side of the firewall. A typi¬ 
cal firewall load balancing configuration with a DMZ is shown in Figure 13-10. 



Private 

Network 


Firewalls 


Web Switches 


Web Switches 


Figure 13-10 Typical Firewall Load-Balancing Topology with DMZ 

The DMZ servers can be attached to the Web switch directly or through an intermediate hub or 
switch. The Web switch is then configured with filters to permit or deny access to the DMZ 
servers. In this manner, two levels of security are implemented: one that restricts access to the 
DMZ through the use of Web switch filters, and another that restricts access to the clean net¬ 
work through the use of stateful inspection performed by the firewalls. 
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You could add the filters required for the DMZ as follows: 

1. On the dirty-side Web switch, create the filter to allow HTTP traffic to reach the DMZ 
Web servers. 

In this example, the DMZ Web servers use IP addresses 205.178.29.0/24. 


>> 

# /cfg/slb/filt 80 

(Select filter 80) 

>> 

Filter 

80# 

sip any 

(From any source IP address) 

>> 

Filter 

80# 

dip 205.178.29.0 

(To the DMZ base destination) 

>> 

Filter 

80# 

dmask 255.255.255.0 

(For the range of DMZ addresses) 

>> 

Filter 

80# 

proto top 

(For TCP protocol traffic) 

>> 

Filter 

80# 

sport any 

(From any source port) 

>> 

Filter 

80# 

dport http 

(To an HTTP destination port) 

>> 

Filter 

80# 

action allow 

(Allow the traffic) 

>> 

Filter 

80# 

ena 

(Enable the filter) 


2. Create another filter to deny all other traffic to the DMZ Web servers. 


» 

Filter 

80# 

.,/filt 89 

(Selectfilter 89) 

» 

Filter 

89# 

sip any 

(From any source IP address) 

» 

Filter 

89# 

dip 205.178.29.0 

(To the DMZ base destination) 

» 

Filter 

89# 

dmask 255.255.255.0 

(For the range of DMZ addresses) 

» 

Filter 

89# 

proto any 

(For TCP protocol traffic) 

» 

Filter 

89# 

action deny 

(Allow the traffic) 

» 

Filter 

89# 

ena 

(Enable the filter) 


NOTE — The deny filter has a higher filter number than the allow filter. This is necessary so 
that the allow filter has the higher order of precedence. 


3. Add the filters to the traffic ingress ports. 


» Filter 89# ../port 1 

(Select the ingress port) 

» SLB Port 1# add 80 

(Add the allow filter) 

» SLB Port 1# add 89 

(Add the deny filter) 

Apply and save the configuration changes. 

>> SLB Port 1# apply 


>> SLB Port 1# save 
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Firewall Health Checks 

Basic FWLB health checking is automatic. No special configuration is necessary unless you 
wish to tune the health checking parameters. See Chapter 10, “Health Checking” for details. 

Firewall Service Monitoring 

To maintain high availability, Web switches monitor firewall health status and send packets 
only to healthy firewalls. There are two methods of firewall service monitoring: ICMP and 
HTTP. Each Web switch monitors the health of the firewalls on a regular basis by pinging the 
IP interfaces configured on its partner Web switch on the other side of the firewall. 

If a Web switch IP interface fails to respond to a user-specified number of pings, it (and, by 
implication, the associated firewall), is placed in a Server Failed state. At this time, the partner 
Web switch stops routing traffic to that IP interface and, instead, distributes it across the 
remaining healthy Web switch IP interfaces and firewalls. 

When a Web switch IP interface is in the Server Failed state, its partner Web switch continues 
to send pings to it at user-configurable intervals. After a specified number of successful pings, 
the IP interface (and its associated firewall) is brought back into service. 

For example, to configure the switch to allow one-second intervals between health checks or 
pings, two failed health checks to remove the firewall, and four successful health checks to 
restore the firewall to the real server group, use the following command: 

/cfg/slb/real <real server number>/ inter 1/retry 2/restr 4 

Physical Link Monitoring 

Web switches also monitor physical link status of switch ports connected to firewalls. If the 
physical link to a firewall goes down, that firewall is placed immediately in the Server Failed 
state. When a Web switch detects that a failed physical link to a firewall has been restored, it 
brings the firewall back into service. 
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Using HTTP Health Checks 

For those firewalls that do not permit ICMP pings to pass through, Web switches can be con¬ 
figured to perform HTTP health checks, as described below. 

1. Set the health check type to HTTP instead of ICMP. 


>> # /cfg/slb/group 1/health http (Select HTTP health checks) 


2. Configure a “dummy” redirect filter as the last filter (after the redirect all filter) to force 
the HTTP health checks to activate, as shown below: 


>> 

# /cfg/slb/filt 224 

(Select filter 224) 

>> 

Filter 

224# 

proto tcp 

(For TCP protocol traffic) 

>> 

Filter 

224# 

action redir 

(Redirect the traffic) 

>> 

Filter 

224# 

group 1 

(Set real server group for redirection) 

>> 

Filter 

224# 

rport http 

(Set real server port for redirection) 

>> 

Filter 

224# 

ena 

(Enable the filter) 


NOTE — Make sure that the number of each real filter is lower than the number of the “dummy” 
redirect filter. 
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Chapter 14 

Virtual Private Network Load 
Balancing 


The VPN (Virtual Private Network) load balancing feature in Web OS 9.0 allows the switch to 
load balance simultaneously up to 255 VPN devices. The switch records from which VPN 
server a session was initiated and ensures that the traffic returns back to the same VPN server 
from which the session started. 


Overview 


Virtual Private Networks 

A VPN is a connection that has the appearance and advantages of a dedicated link, but it 
occurs over a shared network. Using a technique called tunneling , data packets are transmitted 
across a routed network, such as the Internet, in a private tunnel that simulates a point-to-point 
connection. This approach enables network traffic from many sources to travel via separate 
tunnels across the infrastructure. It also enables traffic from many sources to be differentiated, 
so that it can be directed to specific destinations and receive specific levels of service. 

VPNs provide security features of a firewall, network address translation, data encryption, and 
authentication and authorization. Since most of the data sent between VPN initiators and ter¬ 
minators is encrypted, network devices cannot use information inside the packet to make intel¬ 
ligent routing decisions. 
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How VPN Load Balancing Works 


VPN load balancing requires that all ingress traffic passing through a particular VPN must 
traverse the same VPN as it egresses back to the client. Traffic ingressing from the Internet is 
usually addressed to the VPNs, with the real destination encrypted inside the datagram. Traffic 
egressing the VPNs into the intranet contains the real destination in the clear. 

Using the hash algorithm on the source and destination address may not be possible in many 
VPN/firewall configurations because the address may be encrypted inside the datagram. Also, 
the source/destination IP address of the packet may change as the packet traverses from the 
dirty-side switches to clean-side switches and back. 

To support VPN load balancing, the Alteon Web switch records state on frames entering the 
switch to and from the VPNs. This session table ensures that the same VPN server handles all 
the traffic between an inside host and an outside client for a particular session. 


NOTE — VPN load balancing is supported for connecting from remote sites to the network 
behind the VPN cluster IP address. Connection initiated from clients internal to the VPN gate¬ 
ways is not supported. 


Basic frame flow, from the dirty side of the network to the clean side, is shown in Figure 5-1. 
An external client is accessing an internal server. No Network Address Translation (NAT) is 
performed by the VPN devices. 



© ; 


SMAC DMAC SIP DIP 



l£) | ClJtf.O |M0IW | X-1 | 0.1 | I' 2 | E.iq | 

&crypted 


SMAC DMAC SIP DIP 'L 'A 


D. 2 
X.1 

E. 10 
C.1 


= Client IP address 

= IP address use by the VPN client SW 
= IP address of the server 
= Cluster IP address of the VPN devices 


Figure 14-1 Basic Network Frame Flow and Operation 
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The basic steps that occur at the switches when a request arrives from the Internet are 
described below: 

1. The user prepares to send traffic to the destination server. 

2. The VPN client software encrypts the packet and sends it to the cluster IP address of the 
VPN devices. 

3. Switch 1 (SW1) makes an entry in the session table and forwards the packet to VPN 
device 1. 

The selection of the VPN device is based on the hash load-balancing metric. 

4. The VPN device strips the IP header and decrypts the encrypted IP header. 

5. Switch 2 (SW2) forwards the packet to E.10. 

If an entry is found, the frame is forwarded normally. If an entry is not found, the switch deter¬ 
mines which VPN device processed the frame by performing a lookup with the source MAC 
address of the frame. If the MAC address matches a MAC address of a real VPN server, the 
switch adds an entry to the session table so that reverse traffic is redirected to the same VPN 
server. Finally, the frame is forwarded normally. 

VPN Load-Balancing Configuration 


Requirements 

■ Configure the switch with firewall load balancing. For more information, see “Firewall 
Load Balancing” on page 229. 

■ Enable the Return to Sender (RTS) feature on the ports attached to the VPN devices, using 
the following command: 


» # /cfg/slb/port <port number >/rts ena 
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VPN Load-Balancing Configuration Example 

The following example uses Alteon Web switches for VPN load balancing. The configuration 
is for four Web switches, four subnets, and two VPN devices. 



Static Routes fBoth Dirtv 

Alteons): 

20.0.0.10 via 10.0.0.101 if 2 
20.0.0.11 via 10.0.0.102 if 3 
20.0.0.20 via 10.0.0.101 if 2 
20.0.0.21 via 10.0.0.102 if 3 


VPN Static Routes(both): 

default via 10.0.0.1 
30.0.0.0/24 via 20.0.0.1 


Static Routes (Both Clean 

Alteonsl: 

10.0.0.10 via 20.0.0.101 if 2 
10.0.0.11 via 20.0.0.102 if 3 
10.0.0.20 via 20.0.0.101 if 2 
10.0.0.21 via 20.0.0.102 if 3 


Null ethernet (crossover) cables 


Figure 14-2 VPN Load-Balancing Configuration Example 

Build the topology illustrated in Figure 14-2 on page 270, and configure the switches as fol¬ 
lows. 

Configure the First Clean-Side Switch (CA) 

1. Turn off BOOTP. 

>> # /cfg/sys/bootp dis 

2. Define and enable VLAN 2 for ports 7, and 8. 

>> # /cfg/vlan 2/ena/def 7 8 
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3. Turn off Spanning Tree Protocol (STP). 


» # /cfg/stp/off 


4. Define the clean-side IP interfaces. 

Create one clean-side IP interface on a different subnet for each VPN device being load bal¬ 
anced. 


>> 

# 

/cfg/ip/if 

1/ena 

(Select IP interface 1 and enable) 

>> 

IP 

Interface 

1# 

mask 255.255.255.0 

(Set subnet mask for inteiface 1) 

>> 

IP 

Interface 

1# 

addr 30.0.0.10 

(Set IP address for interface 1) 

>> 

IP 

Interface 

1# 

vlan 1 

(For VLAN 1) 

>> 

IP 

Interface 

1# 

. . /if 2/ena 

(Select IP interface 2 and enable) 

>> 

IP 

Interface 

2# 

mask 255.255.255.0 

(Set subnet mask for interface 2) 

>> 

IP 

Interface 

2# 

addr 20.0.0.10 

(Set IP address for interface 2) 

>> 

IP 

Interface 

2# 

vlan 2 

(For VLAN 2) 

>> 

IP 

Interface 

2# 

../if 3/ena 

(Select IP interface 3 and enable) 

>> 

IP 

Interface 

3# 

mask 255.255.255.255 

(Set subnet mask for interface 3) 

>> 

IP 

Interface 

3# 

addr 20.0.0.11 

(Set IP address for interface 3) 

>> 

IP 

Interface 

3# 

vlan 2 

(For VLAN 2) 


5. Configure routes for each of the IP interfaces you configured in Step 4 using the VPN 
devices as gateways. 

One static route is required for each VPN device being load balanced. 


» 

# 

/cfg/ip/route 



» 

IP 

Static 

Route# 

add 10.0.0.10 

(Static route destination IP address) 

» 

IP 

Static 

Route# 

255.255.255.255 

(Destination subnet mask) 

» 

IP 

Static 

Route# 

20.0.0.101 

(Enter gateway IP address) 

» 

IP 

Static 

Route# 

2 

(For interface 2) 

» 

IP 

Static 

Route# 

add 10.0.0.11 

(Enter destination IP address) 

» 

IP 

Static 

Route# 

255.255.255.255 

(Destination subnet mask) 

» 

IP 

Static 

Route# 

20.0.0.102 

(Enter gateway IP address) 

» 

IP 

Static 

Route# 

3 

(For interface 3) 

» 

IP 

Static 

Route# 

add 10.0.0.20 

(Enter destination IP address) 

» 

IP 

Static 

Route# 

255.255.255.255 

(Destination subnet mask) 

» 

IP 

Static 

Route# 

20.0.0.101 

(Enter gateway IP address) 

» 

IP 

Static 

Route# 

2 

(For interface 2) 

» 

IP 

Static 

Route# 

add 10.0.0.21 

(Static route destination IP address) 

» 

IP 

Static 

Route# 

255.255.255.255 

(Destination subnet mask) 

» 

IP 

Static 

Route# 

20.0.0.102 

(Enter gateway IP address) 

» 

IP 

Static 

Route# 

3 

(For interface 3) 
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6. Configure VRRP for virtual routers 1 and 2. 


>> 

# /cfg/vrrp/on 


( Enable VRRP) 

>> 

Virtual Router Redundancy Protocolt 

vr 

1 (Select virtual router 1 menu) 

>> 

VRRP 

Virtual Router 1# ena 


(Enable the virtual router) 

>> 

VRRP 

Virtual Router 1# vrid 1 


(Assign virtual router ID 1) 

>> 

VRRP 

Virtual Router 1# if 1 


(To interface number 1) 

>> 

VRRP 

Virtual Router 1# prio 101 


(Set the renter priority) 

>> 

VRRP 

Virtual Router 1# addr 30.0.0. 

50 

(Set IP address of virtual router) 

>> 

VRRP 

Virtual Router 1# share dis 


(Disable sharing) 

>> 

VRRP 

Virtual Router 1# track 


(Select virtual router tracking menu ) 

>> 

VRRP 

VR 1 Priority Tracking# vrs ena 

(Enable tracking of virtual routers) 

>> 

VRRP 

VR 1 Priority Tracking# apply 


(Apply the configuration ) 

>> 

VRRP 

VR 1 Priority Tracking# save 


(Save the configuration) 

>> 

VRRP 

VR 1 Priority Tracking# . ./vr 

2 

(Select virtual router 2 menu) 

>> 

VRRP 

Virtual Router 2# ena 


(Enable the virtual router) 

>> 

VRRP 

Virtual Router 2# vrid 2 


(Assign virtual router ID 2) 

>> 

VRRP 

Virtual Router 2# if 2 


(To interface number 2) 

>> 

VRRP 

Virtual Router 2# prio 101 


(Set the renter priority) 

>> 

VRRP 

Virtual Router 2# addr 20.0.0. 

1 

(Set IP address of virtual router) 

>> 

VRRP 

Virtual Router 2# share dis 


(Disable sharing) 

>> 

VRRP 

Virtual Router 2# track 


(Select Virtual Router Tracking Menu) 

>> 

VRRP 

VR 2 Priority Tracking# ports 

ena 

(Track VLAN switch ports) 

>> 

VRRP 

VR 2 Priority Tracking# apply 


(Apply the configuration) 

>> 

VRRP 

VR 2 Priority Tracking# save 


(Save the configuration) 

Enable Server Load Balancing (SLB) on the first clean switch. 

>> 

# /cfg/slb/on 



Configure real servers for health checking VPN devices. 

>> 

# /cfg/slb/real 1/ena 


(Enable sib for real server 1 ) 

>> 

Real 

server 1 # rip 10.0.0.10 


(Assign IP address for real server 1 ) 

>> 

Real 

server 1 # ../real 2/ena 


( Enable SLB for real server 2) 

>> 

Real 

server 2 # rip 10.0.0.11 


(Assign IP address for real server 2) 

>> 

Real 

server 2 # ../real 3/ena 


(Enable SLB for real server 3) 

>> 

Real 

server 3 # rip 10.0.0.20 


(Assign IP address for real server 3) 

>> 

Real 

server 3 # ../real 4/ena 


(Enable SLB for real server 4) 

>> 

Real 

server 4 # rip 10.0.0.21 


(Assign IP address for real server 4) 
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9. Configure real server group 1, and add real servers 1, 2,3, and 4 to the group. 


» # /cfg/slb/group 1 (Configure real seri’er group 1) 

» Real server group 1# metric hash (Select SLB hash metric for group 1) 

» Real server group 1# add 1 (Add real servers 1-4 to group 1) 

» Real server group 1# add 2/add 3/add 4 


10. Enable RTS on the necessary ports. 


>> # /cfg/slb/port 7/rts ena (Enable Return to Sender on port 7) 

» # /cfg/slb/port 8/rts ena (Enable Return to Sender on port 8) 


11. Enable filter processing on the server ports so that the responses from the real server will 
be looked up in the VPN session table. 


» # /cfg/slb/port 1/filter ena 


12. Apply and save the configuration, and reboot the switch. 

>> # apply 

>> # save 

» # /boot/reset 

Configure the Second Clean-Side Switch (CB) 

1. Turn off bootp. 

>> # /cfg/sys/bootp dis 

2. Define and enable VLAN 2 for ports 7 and 8. 

» # /cfg/vlan 2/ena/def 7 8 

3. Turn off Spanning Tree Protocol. 

>> # /cfg/stp/off 
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4. Define the clean-side IP interfaces. 

Create one clean-side IP interface on a different subnet for each VPN device being load bal¬ 
anced. 


>> # /cfg/ip/if 1/ena/mask 255.255.255.0/addr 30.0.0.11 
>> # /cfg/ip/if 2/ena/mask 255.255.255.0/addr 20.0.0.20/vl 2 
>> # /cfg/ip/if 3/ena/mask 255.255.255.255/addr 20.0.0.21/vl 2 


5. Configure routes for each of the IP interfaces you configured in Step 4, using the VPN 
devices as gateways. 

One static route is required for each VPN device being load balanced. 


>> 

# 

/cfg/ip/route 




>> 

# 

add 10.0.0.10 

255.255.255.255 

20.0.0.101 

2 

>> 

# 

add 10.0.0.11 

255.255.255.255 

20.0.0.102 

3 

>> 

# 

add 10.0.0.20 

255.255.255.255 

20.0.0.101 

2 

>> 

# 

add 10.0.0.21 

255.255.255.255 

20.0.0.102 

3 


6. Configure Virtual Router Redundancy Protocol (VRRP) for virtual routers 1 and 2. 


>> 

>> 

# /cfg/vrrp/on 

Virtual Router Redundancy Protocol# vr 1 

>> 

VRRP 

Virtual 

Router 

1# 

ena 

>> 

VRRP 

Virtual 

Router 

1# 

vrid 1 

>> 

VRRP 

Virtual 

Router 

1# 

if 1 

>> 

VRRP 

Virtual 

Router 

1# 

addr 30.0.0.50 

>> 

VRRP 

Virtual 

Router 

1# 

share dis 

>> 

VRRP 

Virtual 

Router 

1# 

track/vrs ena 

>> 

VRRP 

Virtual 

Router 

1 ] 

Priority Tracking# /cfg/vrrp/vr 2 

>> 

VRRP 

Virtual 

Router 

2# 

ena 

>> 

VRRP 

Virtual 

Router 

2# 

vrid 2 

>> 

VRRP 

Virtual 

Router 

2# 

if 2 

>> 

VRRP 

Virtual 

Router 

2# 

addr 20.0.0.1 

>> 

VRRP 

Virtual 

Router 

2# 

share dis 

>> 

VRRP 

Virtual 

Router 

2# 

track/ports ena 


7. Enable SLB. 


>> VRRP Virtual Router 2 Priority Tracking# /cfg/slb/on 
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8. Configure real servers for health checking VPN devices. 


» Layer 4 # /cfg/slb/real 1/ena/rip 10.0.0.10 
» Real server 1# ../real 2/ena/rip 10.0.0.11 
» Real server 2# ../real 3/ena/rip 10.0.0.20 
» Real server 3# ../real 4/ena/rip 10.0.0.21 


9. Enable the real server group. 


>> Real server 4# ../group 1 

» Real server group 1# metric hash 

» Real server group 1# add 1/add 2/add 3/add 4 


10. Enable RTS on the necessary ports. 


>> Real server group 1# ../port 7/rts ena 
>> SLB port 7# ../port 8/rts ena 


11. Enable filter processing on the server ports so that the response from the real server will 
be looked up in VPN session table. 


» SLB port 8# ../port 1/filter ena 


12. Apply and save the configuration, and reboot the switch. 


>> 

SLB 

port 

CO 

apply 

>> 

SLB 

port 

8# 

save 

>> 

SLB 

port 

8# 

/boot/reset 


Configure the First Dirty-Side WebSwitch (DA) 

1. Turn off BOOTP. 

» # /cfg/sys/bootp dis 

2. Define and enable VLAN 2 for ports 7 and 8. 

>> # /cfg/vlan 2/ena/def 7 8 
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3. Turn off STP. 


>> # /cfg/stp/off 


4. Configure IP interfaces 1,2, and 3. 


>> # /cfg/ip/if 1/ena/mask 255.255.255.0/addr 192.168.10.10 
>> # /cfg/ip/if 2/ena/mask 255.255.255.0/addr 10.0.0.10/vl 2 
>> # /cfg/ip/if 3/ena/mask 255.255.255.255/addr 10.0.0.11/vl 2 


5. Define static routes for each of the IP interfaces you configured in Step 4, using the VPN 
devices as gateways. 

One static route is required for each VPN device being load balanced. 


>> 

# 

/cfg/ip/route 




>> 

# 

add 20.0.0.10 

255.255.255.255 

10.0.0.101 

2 

>> 

# 

add 20.0.0.11 

255.255.255.255 

10.0.0.102 

3 

>> 

# 

add 20.0.0.20 

255.255.255.255 

10.0.0.101 

2 

>> 

# 

add 20.0.0.21 

255.255.255.255 

10.0.0.102 

3 


6. Configure VRRP for virtual routers 1 and 2. 


>> 

>> 

# /cfg/vrrp/on 

Virtual Router Redundancy Protocol# /cfg/vrrp/vr 1 

>> 

VRRP 

Virtual 

Router 

1# ena 

>> 

VRRP 

Virtual 

Router 

1# vrid 1 

>> 

VRRP 

Virtual 

Router 

1# if 1 

>> 

VRRP 

Virtual 

Router 

1# prio 101 

>> 

VRRP 

Virtual 

Router 

1# addr 192.168.10.50 

>> 

VRRP 

Virtual 

Router 

1# share dis 

>> 

VRRP 

Virtual 

Router 

1# track 

>> 

VRRP 

Virtual 

Router 

1 Priority Tracking# vrs ena 

>> 

VRRP 

Virtual 

Router 

1 Priority Tracking# ports ena 

>> 

VRRP 

Virtual 

Router 

1 Priority Tracking# /cfg/vrrp/vr 2 

>> 

VRRP 

Virtual 

Router 

2# ena 

>> 

VRRP 

Virtual 

Router 

2# vrid 2 

>> 

VRRP 

Virtual 

Router 

2# if 2 

>> 

VRRP 

Virtual 

Router 

2# prio 101 

>> 

VRRP 

Virtual 

Router 

2# addr 10.0.0.1 

>> 

VRRP 

Virtual 

Router 

2# share dis 

>> 

VRRP 

Virtual 

Router 

2# track 

>> 

VRRP 

Virtual 

Router 

2 Priority Tracking# vrs ena 

>> 

VRRP 

Virtual 

Router 

2 Priority Tracking# ports ena 
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7. Enable SLB. 


» VRRP Virtual Router 1 Priority Tracking# /cfg/slb/on 


8. Configure real servers for health-checking VPN devices. 


>> Layer 4# real 1/ena/rip 20.0.0.10 
>> Real server 1# ../real 2/ena/rip 20.0.0.11 

>> Real server 2# ../real 3/ena/rip 20.0.0.20 

>> Real server 3# ../real 4/ena/rip 20.0.0.21 


9. Enable the real server group. 


» Real server 1# ../group 1 

>> Real server group 1# metric hash 

>> Real server group 1# add 1/add 2/add 3/add 4 


10. Configure the filters to allow local subnet traffic on the dirty side of the VPN device to 
reach the VPN device interfaces. 


» # . ./filt 100 
» # ena 

» # sip any 

» # dip 192.168.10.0/dmask 255.255.255.0 

» # action allow 
» # ../filt 110 
>> # ena 

>> # sip any 

» # dip 224.0.0.0/dmask 255.0.0.0 

>> # action allow 


11. Create a filter to allow the management firewall (Policy Server) to reach the VPN firewall. 


» # ../filt 120 ena 
» # sip 192.168.10.120 
» # smask 255.255.255.255 
» # dip 10.0.0.0 
>> # dmask 255.255.255.0 
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12. Create the redirection filter and enable firewall load balancing. 

This filter will redirect inbound traffic, redirecting it among the defined real servers in the group. 



13. Add filters to the ingress port. 


>> # ../port 1 
>> # filt ena 

>> # add 100/add 110/add 224 


14. Apply and save the configuration, and reboot the switch. 


>> # apply 

>> # save 

>> # /boot/reset 


Configure the Second Dirty-Side WebSwitch (DB) 

1. Turn off BOOTP. 

>> # /cfg/sys/bootp dis 

2. Define and enable VLAN 2 for ports 7 and 8. 

>> # /cfg/vlan 2/ena/def 7 8 

3. Turn off STP. 

>> # /cfg/stp/off 

4. Configure IP interfaces 1,2, and 3. 


>> # /cfg/ip/if 1/ena/mask 255.255.255.0/addr 192.168.10.11 
>> # /cfg/ip/if 2/ena/mask 255.255.255.0/addr 10.0.0.20/vl 2 
>> # /cfg/ip/if 3/ena/mask 255.255.255.255/addr 10.0.0.21/vl 2 
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5. Configure routes for each of the IP interfaces you configured in Step 4. 


» # /cfg/ip/route 

» # add 20.0.0.10 255.255.255.255 10.0.0.101 2 
» # add 20.0.0.11 255.255.255.255 10.0.0.102 3 
» # add 20.0.0.20 255.255.255.255 10.0.0.101 2 
» # add 20.0.0.21 255.255.255.255 10.0.0.102 3 


6. Configure VRRP for virtual routers 1 and 2. 



7. Enable SLB. 


» # /cfg/slb/on 


8. Configure real servers for health checking VPN devices. 


>> # /cfg/slb/real 1/ena/rip 20.0.0.10 
>> # /cfg/slb/real 2/ena/rip 20.0.0.11 
>> # /cfg/slb/real 3/ena/rip 20.0.0.20 
>> # /cfg/slb/real 4/ena/rip 20.0.0.21 
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9. Enable the real server group, and place real servers 1-4 into the real server group. 


>> # /cfg/slb/group 1 

>> # metric hash 

>> # add 1/add 2/add 3/add 4 


10. Configure the filters to allow local subnet traffic on the dirty side of the VPN device to 
reach the VPN device interfaces. 


>> 

# 

/cfg/sib/filt 

100 

>> 

# 

ena 





>> 

# 

sip 

any 




>> 

# 

dip 

192 

168 

10 

.0/dmask 255.255.255.0 

>> 

# 

../filt 

110 



>> 

# 

ena 





>> 

# 

sip 

any 




>> 

# 

dip 

224 

0.0 

0/dmask 255.0.0.0 


11. Create the redirection filter and enable firewall load balancing. 

This filter will redirect inbound traffic, among the defined real servers in the group. 



>> # /cfg/slb/port 1 
>> # filt ena 

» # add 100/add 110/add 224 


13. Apply and save the configuration and reboot the switch. 


>> # apply 

>> # save 

>> # /boot/reset 
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Test Configurations and General Topology 

The switches should be able to health check each other, and all switches should see four real 
servers up. (Rules on the VPN devices permit this—see Figure 14-3 on page 281.) 


<3 ffi | eS” 1, iT ” ■& 1, I® 1 S'B'ffife. 

zk Security Policy-VPN-LAB-C0NFIB1 |grj Address Translation-VPN-L4.B-C0NFIG1 | 



Figure 14-3 Checkpoint Rules for Both VPN Devices as Seen in the Policy Editor 
1. Disconnect the cables (cause failures) to change the available servers that are up. 


» # /info/slb/dump 


(Verify which seivers are up) 


This should change the VRRP preferences. You can view VRRP preferences using the CLI 
command /info/vrrp. 

2. Use the Checkpoint Log Viewer to watch for accepted and dropped traffic. In the tool bar 
above, click on Window, then Log Viewer. 


NOTE — To help simplify the logs, the health checks are not logged. 


Alteon Web Systems 

050159A, May 2001 


Chapter 14: Virtual Private Network Load Balancing ■ 281 







































Web OS 9.0 Application Guide 


Test the VPN 

1. Launch the SecuRemote client on the dirty side of the network. 

2. Add a new site. 



3. Enter the policy server IP address: 192.168.10.120. You have the option of adding a 
nickname. 

4. Launch a browser (such as Netscape or Internet Explorer) and go to http://30.0.0.100 

5. You will be asked to authenticate yourself. 

6. Enter vpnuser for user name and alteon for the password. 
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7. You will see a message verifying that you were authenticated. 



8. Browse to the Web site. 

If there are other services running on other servers in the internal network, you should also be 
able to reach those services. All of this traffic is traveling over the VPN and is being decrypted 
at the VPN device. You can verify which VPN device is being used by looking at the Log 
Viewer. You should also be able to see the client authentication as well as the decrypted traffic. 

To verify that the FWLB and hash metric is working correctly on the dirty-side switches (that 
is, hashed on client IP address/Destination IP address), you can configure your current client 
with an IP address one higher (or lower) in the last octet, and try to reestablish the VPN con¬ 
nection. Or, add another PC on the dirty side and connect. 


NOTE — When many clients are coming from behind a VPN gateway (for example, not using 
the SecuRemote clients but using a VPN 1 Gateway or other compatible VPN Gateway), you 
will not see load balancing across those clients. Each SecuRemote client will be treated differ¬ 
ently, but each VPN 1 Gateway will be treated as one client each (that is, one Client IP 
address). VPN Device 1 and VPN Device 2 belong to one cluster IP. 
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Chapter 15 

Content Intelligent Switching 


The following topics are described in this chapter: 

■ Content Switching Overview 

■ URL-Based Web Cache Redirection 

■ URL-Based Server Load Balancing 

■ HTTP Header Inspection 

■ No Cache/Cache Control for WCR 

■ Virtual Hosting 

■ Browser-Smart Load Balancing 

■ Cookie-Based Preferential Load Balancing 

■ URL Hashing 

■ Exclusionary String Matching for URL SLB 

■ Regular Expression Matching 

■ Content Precedence Lookup 

NOTE — Virtual Matrix Architecture (VMA) should be enabled when using any content-intelli¬ 
gent switching feature. Prior to enabling VMA, you must either enable Direct Access Mode 
(DAM) or configure a proxy IP address on all switch ports (except port 9). 
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Content Switching Overview 


Working with session content places heavier demands upon the Web switch than examining 

TCP/IP headers for the following reasons: 

■ Content is non-deterministic. Content identifiers such as URLs and cookies can be of 
varying lengths and can appear at unpredictable locations within a request. Scanning ses¬ 
sion traffic for a specific string is far more processor-intensive than looking at a known 
location in a session for a specific number of bytes. 

■ To parse a content request, the Web switch must temporarily terminate the TCP connec¬ 
tion from the client. This temporary termination is called a delayed binding. While the 
connection is suspended, the Web switch acknowledges the client connection on behalf of 
the server, buffers and examines the client request, and finally opens a connection to an 
appropriate server based on the requested content. 

■ Delayed binding causes two independent TCP connections to span a Web session: one 
from the client to the Web switch and the second from the Web switch to the selected 
server. The Web switch must modify the TCP header, including performing TCP sequence 
number translation and recalculating checksums on every packet that travels between the 
client and the server, for the duration of the session. This function, known as TCP connec¬ 
tion splicing, heavily tasks a Web switch, particularly when the switch must process thou¬ 
sands of these sessions simultaneously. 

■ In addition to real-time traffic and connection processing, a content intelligent Web switch 
must monitor servers to ensure that requests are forwarded to the best-performing and 
healthiest servers. This monitoring involves more than simple ICMP or TCP connection 
tests, as servers can continue to process network protocols while failing to retrieve con¬ 
tent. 

■ If content is segregated in different servers or server farms, the Web switch must provide a 
flexible, user-customizable mechanism allowing a relevant set of application and content 
tests to be applied to each server or server farm. 
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1 . Client requests 

2. 

a Web page -► 

^ - ) 

3. Client sends an r 

4. 

HTTP request >-► 







6. 


Switch completes 3-way Requests for static 

handshake with client data go to caches 


Switch parses the HTTP request 
and forwards based on header 
and URL information - 


File types: 

"images" 

".gif" 

"ipg" 

".html" 



Switch gets response, 
adjusts sequence numbers, 
and forwards the packet 
to the client 


5. Web server receives 
the HTTP request and 


responds 


Figure 15-1 Content Intelligent Load Balancing Example 

To implement content intelligent switching, Alteon Web switches perform numerous process¬ 
ing tasks for each incoming session, including connection setup, traffic parsing, applying 
server selection algorithms, splicing connections and translating session addresses, metering 
and controlling server bandwidth usage, processing traffic filters, collecting statistics, and so 
on. These functions are executed whenever a new request arrives. In addition, the switch per¬ 
forms background functions, such as updating network topology, measuring server perfor¬ 
mance, health checking for servers, applications, and server sites, and so forth, on a periodic 
basis. 
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URL-Based Web Cache Redirection 


By separating static and dynamic content requests via URL parsing, Web OS enables you to send 
requests with specific URLs or URL substrings to designated cache servers. The URL-based 
Web Cache Redirection (WCR) option allows you to perform cache server farm tuning and off¬ 
load overhead processing from the cache servers by only sending appropriate requests to the 
cache server farm. 


NOTE - Both HTTP 1.0 and HTTP 1.1 requests are supported. 


Each request is examined and handled as described below: 

■ If the request is a non-GET request such as HEAD, POST, PUT, or HTTP with cookies, it 
is not sent to the cache. 

■ If the request is an ASP or CGI request or a dynamically generated page, it is not sent to 
the cache. 

■ If the request is a cookie, it can optionally bypass the cache. 

Network administrators can configure up to 32 URL expressions, each 8 bytes long, for non¬ 
cacheable content types. Up to 128 strings (on an Alteon 180e, Alteon 184, Alteon AD3, and 
Alteon AD4 Web switch), comprising 40 bytes each, can be used for URL substring matching 
on each switch. As each URL Web request is examined, noncacheable items are forwarded to 
the origin server while requests with substring matches are redirected to the appropriate cache 
server. 


NOTE — The term origin server refers to the server originally specified in the request. 


Examples of substrings are: 

■ “/product”: matches URL that starts with “/product,” including any information in the 
“/product” directory 

■ “product”: matches URL that has the string “product” anywhere in the entire URL 
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The switch is preconfigured with a list of 13 noncacheable items that the network administrator 
can add to, delete, or modify. These items are either known dynamic content file extensions or 
dynamic URL parameters, as described below: 

■ dynamic content file extensions: cgi (cgi files) 

■ cfm (cold fusion files), .asp (ASP files), bin (bin directory), cgi-bin (cgi-bin directory), 
shtml (scripted html), .htx (Microsoft HTML extension file), .exe (executable) 

■ dynamic URL parameters: +, !, %, =, & 


Host B 


Host A 


// 


3 


Internet 


/S' -x^ vc : 




,|c9 v 


.'OVN 


.ISP 






"'"GET/http 1 


■jl tinance.yahoo.c 1 


.com/q^y.^P 0 - 0 : 


1 2C+ibm 0 /odty. 1 . 



Host C 



within the group 


Figure 15-2 URL-Based Web Cache Redirection 


Requests will be load balanced among the multiple servers matching the URL according to the 
metric specified for the server group (leastconns is the default). 
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Options for Network Address Translation 

URL-based WCR supports three types of Network Address Translation (NAT). You may 
choose any one depending upon how you want to change the addresses for sending traffic to 
the Web Cache. 

No NAT 

In this NAT method, the traffic is redirected to the Web cache with the destination MAC 
address replaced by the MAC address of the cache. The destination IP address remains 
unchanged, and no modifications are made to the IP address or the MAC address of the source 
or origin server. This works well for transparent cache servers, which process traffic destined 
to their MAC address but with the IP address of some other device. 

Half NAT 

In this most commonly used NAT method, the destination IP address is replaced by the IP 
address of the Web cache, and the destination MAC address is replaced by the MAC address of 
the Web cache. Both the IP address and the MAC address of the source remain unchanged. 

Full NAT 

In this NAT method, the IP address and the MAC address of the source are replaced by the IP 
address and MAC address of the Web cache. This method works well for proxy cache servers. 
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Configuring URL-Based Web Cache Redirection 

To configure URL-based Web Cache Redirection (WCR), perform the following steps: 

1. Before you can configure URL-based WCR, configure the switch for basic Server Load 
Balancing (SLB). This includes the following tasks: 

■ Assign an IP address to each of the real servers in the server pool. 

■ Define an IP interface on the switch. 

■ Define each real server. 

For information on how to configure your network for SLB, see “Server Load Balancing” on 
page 67. 

2. Configure the switch to support basic WCR. 

For information on WCR, refer to “Application Redirection” on page 139. 

3. Configure the parameters and file extensions that will bypass WCR. 

The switch is preconfigured with a list of 13 noncacheable items: 

■ Dynamic content file extensions: .cgi (cgi files), .cfm (cold fusion files), .asp (ASP files), 
bin (bin directory), cgi-bin (cgi-bin directory), .shtml (scripted html), .htx (Microsoft 
HTML extension file), .exe (executable) 

■ Dynamic URL parameters: +, !, %, =, & 

a) Add or remove expressions that should not be cacheable. 

>> # /cfg/slb/url/redir/add | remove <expression> 

b) Enable/disable ALLOW for non-GETS (such as HEAD, POST, and PUT) to the ori¬ 
gin server, as described below. 

>> # /cfg/slb/url/redir/urlal ena|dis 


□ Enable: The switch will allow all non-GET requests to the origin server. 

□ Disable: The switch will compare all requests against the expression table to deter¬ 
mine whether the request should be redirected to a cache server or the origin server. 
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c) Enable/disable cache redirection of requests that contain “cookie: ” in the HTTP 
header. 


>> # /cfg/slb/url/redir/cookie ena|dis 


□ Enable: The switch will redirect all requests that contain “cookie:” in the HTTP 
header to the origin server. 

□ Disable: The switch will compare the URL against the expression table to deter¬ 
mine whether the request should be redirected to a cache server or the origin server. 

d) Enable/disable cache redirection of requests that contain “Cache-control: no 
cache” in the HTTP 1.1 header or “Pragma: no cache” in the HTTP 1.0 header 
to the origin server. 


>> # /cfg/slb/url/redir/nocache ena|dis 


□ Enable: The switch will redirect all requests that contain “Cache-control: no cache” 
in the HTTP 1.1 header or “Pragma:no cache” in the HTTP 1.0 header to the origin 
server. 

□ Disable: The switch will compare the URL against the expression table to deter¬ 
mine whether the request should be redirected to a cache server or the origin server. 

4. Define the string(s) to be used for Web cache SLB. Refer to the parameters listed below: 


>> # /cfg/slb/url/lb/add | rem <string> 


■ add: Add string or a path. 

■ rem: Remove string or a path. 

A default string “any” indicates that the particular server can handle all URL or Web-cache 
requests. A string that starts out with a backslash ( / ), such as “/images,” indicates that if 
this string is applied to a particular server, the server can only handle requests that start out 
with the “/images” string. 
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Example: With the “/images” string, the server will handle the following requests: 

/images/product/b.gif 
/images/company/a.gif 
/images/testing/c.jpg 

This server will not handle these requests: 

/company/images/b.gif 
/product/images/c.gif 
/testing/images/a.gif 

A string that doesn't start out with a backslash ( / ) indicates that if this string is applied to a 
particular server, the server can handle any requests that contain the defined string. 

Example: With the “images” string, the server will handle these requests: 

/images/product/b.gif 
/images/company/a.gif 
/images/testing/c.jpg 
/company/images/b.gif 
/product/images/c.gif 
/testing/images/a.gif 

If a server is configured with only the load balance string ( / ), it will only handle requests to 
the root directory. 

Example: With the “/” string, the server will handle these requests: 

/ 

/index.htm 
/default.asp 
/index.shtm 

Any files in the root directory 

For easy configuration and identification, each defined string has an ID attached, as shown in 
the following example: 

Example: Six entries 


ID 

SLB String 

1 

any 

2 

.gif 

3 

/sales 

4 

/xitami 

5 

/manual 

6 

■ jpg 
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5. Configure the real server(s) to handle WCR. 


NOTE — If you don’t add a defined substring (or add the defined substring “any”), the server 
will handle any request. 


■ To add a defined substring: 

» # /cfg/slb/real 2/layer7/addlb <1D> 

where ID is the identification number of the defined string. 

■ To remove a defined substring: 

» # /cfg/slb/real 2/layer7/remlb <ID> 


The server can have multiple defined substrings. For example: “/images”, “/sales”, “.gif’ 

With these defined strings, this particular server can handle requests that start out with 
“/images” or “/sales” and any requests that contain “. gif" . 

On the switch, define a real server group and add real servers to the real server group. 

This configuration combines the three real servers into one real server group: 


>> 

# /cfg/slb/group 1 




(Select real sen’er group 1) 

>> 

Real 

server 

group 

i# 

add 

1 

(Add reed server 1 to group 1) 

>> 

Real 

server 

group 

i# 

add 

2 

(Add real server 2 to group 1) 

>> 

Real 

server 

group 

i# 

add 

3 

(Add real server 3 to group 1) 
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6. Configure a filter to support basic WCR. 

The filter must be able to intercept all TCP traffic for the HTTP destination port and must redi¬ 
rect it to the proper port in the real server group: 


>> 

# /cfg/slb/f ilt <filter number> 

(Select the menu for Filter #x) 

>> 

Filter 

<filter number> # 

sip any 

(From any source IP addresses) 

>> 

Filter 

<filter number> # 

dip any 

(To any destination IP addresses) 

>> 

Filter 

<filter number> # 

proto 

tcp 

(For TCP protocol traffic) 

>> 

Filter 

<filter number> # 

sport 

any 

(From any source port) 

>> 

Filter 

<filter number> # 

dport 

http 

(To an HTTP destination port) 

>> 

Filter 

<filter number> # 

action redir 

(Set the action for redirection) 

>> 

Filter 

<filter number> # 

rport 

http 

(Set the redirection port) 

>> 

Filter 

<filter number> # 

group 

1 

(Select real server group 1) 

>> 

Filter 

<filter number> # 

ena 


(Enable the filter) 


7. Enable URL-based WCR on the same filter. 


>> # /cfg/slb/filt <filter number> / adv/ur Ip ena 


8. Select the appropriate NAT option. 

The three NAT options are listed below. For more information about each option, see “Options 
for Network Address Translation” on page 290. 

■ No NAT option: 

>> # /cfg/slb/f ilter <filter nwnber>/ adv/proxy dis 

■ Half NAT option: 

>> # /cfg/slb/f ilter <filter number>/ adv/proxy ena 


■ Full NAT option: 


>> # /cfg/slb/f ilt <filter number>/ adv/proxy ena 

>> # ../rport 3128 (This port number is an example) 

» # . . /port <port number> /pip 12.12.12.12 (Configure proxy IP address on 

the physical port) 

» # proxy ena (Enable the proxy IP address) 
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9. On the switch, create a default filter for noncached traffic. 


>> # /cfg/slb/f ilt <filter number> 

» Filter <fliter number ># sip any 

>> Filter <fliter number ># dip any 

>> Filter <filter number ># proto any 

>> Filter <fliter number ># action allow 

>> Filter <fliter number ># ena 

>> Filter <fliter number ># port <portnumber> 


(Select the default filter) 

(From any source IP addresses) 
(To any destination IP addresses) 
(For any protocol traffic) 

(Set the action to allow traffic) 
(Enable the default filter) 

(Assign the default filter to a port) 


NOTE — When the proto parameter is not top or udp, then sport and dport are ignored. 


10. Turn on filtering for the port. 


>> # /cfg/slb/port <port number>/ filt ena 


11. Add the filters to the client port. 


>> # /cfg/slb/port <port number>/ add <filter 

number> 

Enable Direct Access Mode (DAM) on the switch. 


>> # /cfg/slb/adv/direct ena 

On the switch, enable, apply, and verify the configuration. 

>> # /cfg/slb 

(Select the SLB Menu) 

>> # on 

(Turn SLB on) 

>> # apply 

(Make your changes active) 

>> # cur 

(View current settings) 


Statistics for URL-Based Web Cache Redirection 

To show the number of hits to the cache server or origin server, use this command: 


>> # /stats/slb/url/redir 

Total URL based Web cache redirection stats: 


Total cache server hits: 73942 

Total origin server hits: 2244 

Total none-GETs hits: 53467 

Total 'Cookie: ' hits: 729 

Total no-cache hits: 43 
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URL-Based Server Load Balancing 


URL-based SLB allows the network administrator to optimize resource access and server tun¬ 
ing. Content dispersion can be optimized by basing load-balancing decisions on the entire path 
and filename of each URL. 

URL-based load balancing operates in a manner similar to URL parsing for Web cache redirec¬ 
tion except that a virtual server on the switch is the target of all IP/HTTP requests. 


NOTE - Both HTTP 1.0 and HTTP 1.1 requests are supported. 


Network administrators can configure up to 128 strings, comprising 40 bytes each, for URL 
matching. Each URL Web request is then examined against the URL strings defined for each 
real server, as described under “URL-Based Web Cache Redirection” on page 288. URL 
requests will be load balanced among the multiple servers matching the URL, according to the 
metric specified in the real server group (leastConns is the default). 


GET/www.foo.com/images/abc.gif 


GET/www. foo.com/event/reg.bin 


GET/www. foo.com/product/abc.html 



Substring matching for: 
images 
■gif 
■jpg 



Substring matching for: 
■cgi 
.bin 
.exe 


In groups with multiple servers, 
traffic is distributed within the 
group via standard SLB metric 
or URL hashing 



Substring matching for: 
.html 


Figure 15-3 URL-Based Server Load Balancing 


Example: The network administrator specifies the following criteria for load balancing: 

■ Requests with “.cgi” in the URL are forwarded to real servers 1, 2, and 5. 

■ Requests with the substring “images” in the URL are sent to real servers 3, 4, and 6. 

■ Requests with URLs starting with “/product:” are sent to real servers 2, 3, and 5. 

Requests containing URLs with anything else are sent to real servers 1, 2, and 3. These servers 
have been defined with the “any” string. 
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Configuring URL-Based Server Load Balancing 


NOTE — When URL-based SLB is used in an active/active redundant setup, use a proxy IP 
address instead of DAM to enable the URL parsing feature. 


To configure URL-based SLB, perform the following steps: 

1. Before you can configure URL-based load balancing, ensure that the switch has already 
been configured for basic SLB. Configuration includes the following tasks: 

■ Assign an IP address to each of the real servers in the server pool. 

■ Define an IP interface on the switch. 

■ Define each real server. 

■ Define a real server group and set up health checks for the group. 

■ Define a virtual server on virtual port 80 (HTTP), and assign the real server group to ser¬ 
vice it. 

■ Enable SLB on the switch. 

■ Enable client processing on the port connected to the clients. 

For information on how to configure your network for SLB, see “Server Load Balancing” on 
page 67. 

2. Define the string(s) to be used for URL load balancing. Refer to the information and 
examples given below: 

>> # /cfg/slb/url/lb/add|rem <string> 


■ add: Add string or a path. 

■ rem: Remove string or a path. 

A default string “any” indicates that the particular server can handle all URL or Web-cache 
requests. A string that starts out with a backslash ( / ), such as “/images,” indicates that if 
this string is applied to a particular server, the server can only handle requests that start out 
with the “/images” string. 


298 ■ Chapter 15: Content Intelligent Switching 


Alteon ((^Systems 

050159A, May 2001 





Web OS 9.0 Application Guide 


Example: With the “/images” string, the server will handle these requests: 

/images/product/b.gif 
/images/company/a.gif 
/images/testing/c.jpg 

This server will not handle these requests: 

/company/images/b.gif 
/product/images/c.gif 
/testing/images/a.gif 

A string that doesn't start out with a backslash ( / ) indicates that if this string is applied to a 
particular server, the server can handle any requests that contain the defined string. 

Example: With the “images” string, the server will handle these requests: 

/images/product/b.gif 
/images/company/a.gif 
/images/testing/c.jpg 
/company/images/b.gif 
/product/images/c.gif 
/testing/images/a.gif 

If a server is configured only with the load balance string ( / ), it will only handle requests to 
the root directory. 

Example: With the “/” string, the server will handle these requests: 

/ 

/index.htm 
/default.asp 
/index.shtm 

Any files in the ROOT directory 

For easy configuration and identification, each defined string has an ID attached, as shown in 
the following example: 

Example: Number of entries: six 


ID 

SLB String 

1 

any 

2 

.gif 

3 

/sales 

4 

/xitami 

5 

/manual 

6 

■ jpg 


Alteon WebSystems 

050159A, May 2001 


Chapter 15: Content Intelligent Switching ■ 299 





Web OS 9.0 Application Guide 


3. Configure one or more real servers to handle URL-based load balancing. 
■ To add a defined substring, use this command: 


>> # /cfg/slb/real 2/layer7/addlb <ID> 


where ID is the identification number of the defined string. 


NOTE — If you don’t add a defined substring (or add the defined substring “any”), the server 
will handle any request. 


■ To remove a defined substring, use this command: 


» # /cfg/slb/real 2/layer7/remlb <ID> 


The server can have multiple defined substrings. For example: 

■ “/images” 

■ “/sales” 

■ “gif' 

With these defined strings, this particular server can handle requests that start out with 
“/images” or “/sales” and any requests that contain “. gif”. 

4. On the switch, enable SLB. 

>> # /cfg/slb/on (Turn SLB on) 


5. Either enable DAM on the switch or configure a proxy IP address on the client port. 

To use cookie-based preferential load balancing without DAM, you need to configure a proxy 
IP address on the client port. 


NOTE — If VMA is enabled, you need to configure a proxy IP address on ports 1-8. 


On the port used for cookie-based preferential load balancing, enable proxy load balancing. If 
Virtual Matrix Architecture (VMA) is enabled on the switch, you can choose to configure the 
remaining ports with proxy IP disabled. 
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■ To turn on DAM: 


>> # /cfg/slb/adv/direct ena 


■ To turn off DAM and configure a proxy IP address on the client port: 


>> # /cfg/slb/direct dis 
>> # port 2/pip 12.12.12.12 
>> # proxy ena 


NOTE — By enabling DAM on the switch or, alternatively, disabling DAM and configuring a 
Proxy IP address on the client port, port mapping for URL load balancing can be performed. 


6. Enable URL-based SLB on the virtual server(s). 


» # /cfg/slb/virt <virtual server number >/service 80/httpslb ena/urlslb 


Statistics for URL-Based Server Load Balancing 

To show the number of hits to the SLB or cache server, use this command: 


» # /stats/slb/url/lb 


Sample Statistics: 


ID 

SLB String 

Hits 

1 

any 

73881 

2 

.gif 

0 

3 

/sales 

0 

4 

/xitami 

162102 

5 

/manual 

0 

6 

■ jpg 

0 
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HTTP Header Inspection 


HTTP headers are used to include additional information to requests and responses. The HTTP 
1.1 specification defines a total of 46 headers. HTTP headers can be general headers, request 
headers, response headers, and entity headers. General headers may exist in both requests and 
responses. Requests and response headers are specific only to requests and responses, respec¬ 
tively. Entity headers describe the content of the request body or the content of the response 
body. 

Each HTTP header field consists of a name, followed immediately by a colon ( :), a single 
space character, and the field value. Field names are case-insensitive. Header fields can be 
extended over multiple lines by preceding each extra line with at least one space. 


NOTE — One HTTP header is supported globally for the entire switch. 


Customer applications of header inspection are listed below: 

■ Redirection based on domain name 

■ Cachability based on domain name 

■ Virtual hosting 

■ Redirection based on browser type 

■ Cookie-based preferential redirection 

Multiple Frames Processing for Delayed Binding 

In addition to the URI path, which generally is less than 300 bytes, the HTTP GET requests 
also include general headers and request headers. HTTP cookie request headers can be 4500 
bytes in length. A single GET request can include multiple cookies. 

To handle the overall length of HTTP headers, including request headers containing multiple 
cookies, and the Maximum Segment Size (MSS) of dial-up connections, Web OS software 
provides the following support: 

■ Parsing of HTTP GET requests for URI path matching and HTTP headers matching 
beyond the first frame while performing delayed binding 

■ Buffering of a maximum of 4500 bytes in total for a single GET request across multiple 
frames 

■ Processing multiple frames from a single HTTP GET request, using a TCP stack on the 
switch 
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HTTP Header-Based Server Load Balancing 

By configuring HTTP header SLB, you can load balance HTTP requests based on different 
HTTP header information, such as “Cookie:” header for persistent load balancing, “Host:” 
header for virtual hosting, and “User-Agent” for browser-smart load balancing. 


NOTE — Cookie-based persistent load balancing is described in Chapter 16, “Persistence.” Vir¬ 
tual hosting and browser-smart load balancing are discussed in this chapter. 


No Cache/Cache Control for WCR 


Using this feature, you can offload the processing of non-cacheable content from cache servers 
by sending only appropriate requests to the cache server farm. When a Cache-Control header is 
present in a HTTP 1.1 request, it indicates a client's special request with respect to caching, 
such as to guarantee up-to-date data from the origin server. By enabling this feature, HTTP 1.1 
GET requests with the “Cache-Control: no cache” directive in the requests are forwarded 
directly to the origin servers. 


NOTE — For WCR, one HTTP header is supported globally for the entire switch. 


In HTTP 1.0, the equivalent of the HTTP 1.1 Cache-Control: Header is the “Pragma: no-cache” 
header. By enabling this, requests with the “Pragma: no-cache” headers are forwarded to the ori¬ 
gin server. This allows a client to insist upon receiving an authoritative response to its requests. 


Configuring HTTP Header-Based Web Cache Redirection 

By configuring HTTP header WCR, we can redirect Web cache requests based on different HTTP 
header information, such as “Host:” header or “User-Agent” for browser-smart load balancing. 

To configure the switch to do WCR based on the “Host:” header, use the following procedure: 

1. Configure basic SLB. 

Before you can configure header-based cache redirection, ensure that the switch has already 
been configured for basic SLB (see “Server Load Balancing” on page 67). Configuration 
includes the following tasks: 

■ Assign an IP address to each of the real servers in the server pool. 

■ Define an IP interface on the switch. 

■ Define each real server. 

■ Assign servers to real server groups. 

■ Define virtual servers and services. 
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2. Turn on URL parsing for the filter. 


>> # /cfg/slb/filt 1/adv/urlp ena 


3. Enable header load balancing for “Host:” header. 


>> # /cfg/slb/url/redir/header ena host 


4. Define the host names. 


>> # /cfg/slb/url/lb/add ".com" 

>> Server Load Balance Resource# add ".org" 
>> Server Load Balance Resource# add ".net" 


5. Configure the real server(s) to handle the appropriate load balance string(s). 

To add a defined substring: 


>> # /cfg/slb/real 2/layer7/addlb </£>> 


where ID is the identification number of the defined string. 


NOTE — If you don’t add a defined substring (or add the defined substring “any”), the server 
will handle any request. 


6. If Host: header filtering is configured, you can configure the switch to use the host header 
field to determine whether requests are cacheable (or noncacheable). 

Example: If you want all domain names that end with . net or . uk not to go to a cache. 

■ Configure the Host header filter. 

» # /cfg/slb/filt 1/adv/urlp ena 

■ Add in expression entries: 

>> # /cfg/slb/url/redir/add .net .uk 
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7. You can direct a cacheable URL request to a specific cache server by configuring min- 
misses or hash as the metric. The switch will then use the host field in the HTTP 
header and the number of bytes into the URI to calculate the hash key. 

If the host field doesn’t exist and no length was specified, the switch will use the source IP 
address as the hash key. If host field doesn’t exist but the length was specified, the switch will 
use all or part of the URI to calculate the hash key. 


>> # /cfg/slb/url/redir/hash enable|disable 


■ Enable: Enable hashing based on the URI and set the length of the URI that will be used 
to hash into the cache server. 

■ Disable: By disabling hashing based on the URI, the switch will only use the host header 
field to calculate the hash key. 

Example 1: Using the source IP address as the hash key: 

clientl requests http://www.yahoo.com —> cachel 
client2 requests http://www.yahoo.com —> cache2 
client3 requests http://www.yahoo.com — > cache3 

Example 2: Using the host field and/or part or all of the URI, the same URL request will go to 
the same cache: 

clientl requests http://www.yahoo.com —> cachel 
client2 requests http://www.yahoo.com —> cachel 
client3 requests http://www.yahoo.com —> cachel 

Example 3: If the Host field doesn’t exist, but length was specified: 

clientl requests http://www.yahoo.com/sales/index.htm —> cachel 
client2 requests http://www.yahoo.com/sales/index.htm —> cachel 
client3 requests http://www.yahoo.com/sales/index.htm —> cachel 
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Configuring Browser-Based Web Cache Redirection 

To configure User-Agent: header-based WCR, perform the following procedure. 

1. Before you can configure header-based WCR, ensure that the switch has already been 
configured for basic SLB. Configuration includes the following tasks: 

■ Assign an IP address to each of the real servers in the server pool. 

■ Define an IP interface on the switch. 

■ Define each real server. 

■ Assign servers to real server groups. 

■ Define virtual servers and services. 

2. Turn on URL parsing for the filter. 

>> # /cfg/slb/filt 1/adv/urlp enable 

3. Enable header load balancing for “User-Agent:” header. 

>> # /cfg/slb/url/redir/header ena useragent 

4. Define the host names. 

>> # /cfg/slb/url/lb/add "Mozilla" 

>> Server Load Balance Resource# add "Internet Explorer" 

>> Server Load Balance Resource# add "Netscape" 

5. Configure the real server(s) to handle the appropriate load balance string(s). 


NOTE — If you don’t add a defined substring (or add the defined substring “any”), the server 
will handle any request. 


To add a defined substring: 


>> # /cfg/slb/real 2/layer7/addlb <ID> 


where ID is the identification number of the defined string. 


306 ■ Chapter 15: Content Intelligent Switching 


Alteon ((^Systems 

050159A, May 2001 









Web OS 9.0 Application Guide 


Virtual Hosting 


Increasingly, individuals and companies are interested in having a presence on the Internet in 
the form of a dedicated Web site address. They want, for example, to have a “www.site-a.com” 
and “www.site-b.com” instead of “www.hostsite.com/site-a” and “www.hostsite.com/site-b.” 

Service providers, on the other hand, do not want to deplete the pool of unique IP addresses by 
dedicating an individual IP address for each home page they host. By supporting an extension in 
HTTP 1.1 to include the host header, Web OS enables service providers to create a single virtual 
server IP address to host multiple Web sites per customer, each with their own host name. 


NOTE — For SLB, one HTTP header is supported per virtual server. 


The following bullets provide more detail, followed by configuration details. 

■ Currently, an HTTP 1.0 request sent to an origin server (not a proxy server) is a partial 
URL instead of a full URL. 

An example of the request that the origin server would see is: 

GET /products/180/ HTTP/1.0 
User-agent: Mozilla/3.0 

Accept: text/html, image/gif, image/jpeg 

The GET request does not include the host name. From the TCP/IP headers, the origin 
server knows its host name, port number, and the protocol that it speaks. 

■ With the extension to HTTP/1.1 to include the HTTP HOST: header, the above request to 
retrieve the URL ‘Vwww.alteonwebsystems.com/ products/180” would look like this: 

GET /products/180/ HTTP/1.1 
Host: www.alteonwebsystems.com 
User-agent: Mozilla/3.0 

Accept: text/html, image/gif, image/jpeg 

The Host: header carries the hostname used to yield the IP address of the site. 

■ Based on the Host: header, the switch will forward the request to servers representing dif¬ 
ferent customers’ Web sites. 

■ The network administrator needs to define a domain name as part of the 128 supported 
URL substrings. 

■ The switch will perform substring matching; that is, the substring “alteonweb- 
systems.com” or “www.alteonwebsystems.com” will match “www.alteonweb- 
systems.com.” 


Alteon ({h*/ Systems 

050159A, May 2001 


Chapter 15: Content Intelligent Switching ■ 307 





Web OS 9.0 Application Guide 


Virtual Hosting Configuration Overview 

The sequence of events for configuring virtual hosting, based on HTTP Host: headers, is 
described below: 

1. The network administrator defines a domain name as part of the 128 supported URL 
substrings. 

Both domain names “www.company-a.com” and “www.company-b.com” get resolved to the 
same IP address. In this example, the IP address is for a virtual server on the switch. 

2. “www.company-a.com” and “www.company-b.com” are defined as URL substrings. 

3. Server Group 1 is configured with Servers 1 through 8. 

Servers 1 through 4 belong to “www.company-a.com” and Servers 5 through 8 belong to 
“www.company-b.com.” 

4. The network administrator assigns substring “www.company-a.com” to Servers 1 
through 4 and substring “www.company-b.com” to Servers 5 through 8. 

5. Switch inspects the HTTP host header in requests received from the client. 

■ If the host header is “www.company-a.com,” the switch directs requests to one of the 
Servers 1 through 4. 

■ If the host header is “www.company-b.com,” the switch directs requests to one of the 
Servers 5 through 8. 
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Configuring the “Host:” Header for Virtual Hosting 

To configure “Host:” header load balancing to support virtual hosting, perform the following 
procedure: 

1. Before you can configure header-based load balancing, ensure that the switch has 
already been configured for basic SLB. Configuration includes the following tasks: 

■ Assign an IP address to each of the real servers in the server pool. 

■ Define an IP interface on the switch. 

■ Define each real server. 

■ Assign servers to real server groups. 

■ Define virtual servers and services 

For information on how to configure your network for server load balancing, see “Server Load 
Balancing” on page 67. 

2. Turn on URL parsing to the virtual server for virtual hosting. 

» # /cfg/slb/virt 1/service 80/httpslb ena host 

3. Define the host names. 

>> # /cfg/slb/url/lb/add "www.customerl.com" 

» Server Loadbalance Resource# add "www.customer2.com" 

» Server Loadbalance Resource# add "www.customer3.com" 

4. Configure the real server(s) to handle the appropriate load balance string(s). 

To add a defined substring: 


» # /cfg/slb/real 2/layer7/addlb <ID> 


where ID is the identification number of the defined string. 


NOTE — If you don’t add a defined substring (or add the defined substring “any”), the server 
will handle any request. 
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Browser-Smart Load Balancing 


By inspecting the “User-Agent” header, requests can be directed to different servers based on 
browser type. 

To configure “User-Agent:” header load balancing to allow the switch to perform browser- 
smart load balancing, perform the following procedure. 

1. Before you can configure header-based load balancing, ensure that the switch has 
already been configured for basic SLB. Configuration includes the following tasks: 

■ Assign an IP address to each of the real servers in the server pool. 

■ Define an IP interface on the switch. 

■ Define each real server. 

■ Assign servers to real server groups. 

■ Define virtual servers and services. 

2. Turn on URL parsing to the virtual server for “User-Agent:” header. 


>> # /cfg/slb/virt 1/service 80/httpslb ena browser 


3. Define the host names. 


>> # /cfg/slb/url/lb/add "Mozilla" 

>> Server Loadbalance Resource# add "Internet Explorer" 
>> Server Loadbalance Resource# add "Netscape" 


4. Configure the real server(s) to handle the appropriate load balance string(s). 


NOTE — If you don’t add a defined substring (or add the defined substring “any”), the server 
will handle any request. 


To add a defined substring: 


>> # /cfg/slb/real 2/layer7/addlb <ID> 


where ID is the identification number of the defined string. 
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Cookie-Based Preferential Load Balancing 


Cookies can be used to provide preferential services for customers, ensuring that certain users 
are offered better access to resources than other users when site resources are scarce. For 
example, a Web server could authenticate a user via a password and then set cookies to iden¬ 
tify them as “Gold,” “Silver,” or “Bronze” customers. Using cookies, you can distinguish indi¬ 
viduals or groups of users and place them into groups or communities that get redirected to 
better resources and receive better services than all other users. 

Cookie-based preferential services enable the following support: 

■ Redirect higher priority users to a larger server or server group 

■ Identify a user group and redirect them to a particular server 

■ Serve content based on user identity 

■ Prioritize access to scarce resources on a Web site 

■ Provide better services to repeat customers, based on access count 

Clients that will receive preferential service can be distinguished from other users by one of the 
following methods: 

■ Individual User 

Specific individual user could be distinguished by IP address, login authentication, or per¬ 
manent HTTP cookie. 

■ User Communities 

Some set of users, such as “Premium Users” for service providers who pay higher mem¬ 
bership fees than “Normal Users” could be identified by source address range, login 
authentication, or permanent HTTP cookie. 

■ Applications 

Users could be identified by the specific application they are using. For example, giving 
priority to HTTPS traffic that is performing credit card transactions versus HTTP brows¬ 
ing traffic. 

■ Content 

Users could be identified by the specific content they are accessing. 

Based on one or more of the criteria above, you can load balance requests to different server 
groups. 
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Configuring Cookie-Based Preferential Load Balancing 

To configure cookie-based preferential load balancing, perform the following procedure. 

1. Before you can configure header-based load balancing, ensure that the switch has 
already been configured for basic SLB. Configuration includes the following tasks: 

■ Assign an IP address to each of the real servers in the server pool. 

■ Define an IP interface on the switch. 

■ Define each real server. 

■ Assign servers to real server groups. 

■ Define virtual servers and services. 

For information on how to configure your network for SLB, see Chapter 1. 

2. Turn on URL parsing to the virtual server. 

>> # /cfg/slb/virt 1/service 80/httpslb 80 enable cookie sid 1 6 dis 


where 

sid = cookie name 

1 = offset (the starting position of the value to be used for hashing) 
6 = length (the number of bytes in the cookie value) 

3. Define the cookie values. 


» # /cfg/slb/url/lb/add "Gold" 
>> # add "Silver" 

>> # add "Bronze" 


Since a session cookie does not exist in the first request of an HTTP session, a default server or 
“any” server is needed to assign cookies to a “None” cookie HTTP request. 


Example: 


■ Real Server 1 

■ Real Server 2 

■ Real Server 3 

■ Real Server 4 
cookie. 


“Gold” handles gold requests. 

“Silver” handles silver request. 

“Bronze” handles bronze request. 

“any” handles any request that does not have a cookie or matching 
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With servers defined to handle the requests listed above, here is what happens: 

■ Request 1 comes in with no cookie; it is forwarded to Real Server 4 to get cookie assigned. 

■ Request 2 comes in with “Gold” cookie; it will be forwarded to Real Server 1. 

■ Request 3 comes in with “Silver” cookie; it will be forwarded to Real Server 2. 

■ Request 4 comes in with “Bronze” cookie; it will be forwarded to Real Server 3. 

■ Request 5 comes in with “Titanium” cookie; it will be forwarded to Real Server 4, since it 
does not have an exact cookie match. 

4. Configure the real server(s) to handle the appropriate load balance string(s). 

To add a defined substring: 

» # /cfg/slb/real 2/layer7/addlb <ID> 


where ID is the identification number of the defined string. 


NOTE — If you don’t add a defined substring (or add the defined substring “any”), the server 
will handle any request. 
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URL Hashing 


By default, hashing algorithms use the IP source address and/or IP destination address 
(depending on the application area) to determine content location. For example, firewall load 
balancing uses both IP source and destination addresses, WCR uses only the IP destination 
address, and SLB uses only the IP source address. 

If URL-based WCR is enabled and the “Host”: header is present in the URL of an HTTP 
request, you can hash on the header or the URL to determine content location. All requests for 
“www.alteonwebsystems.com,” for example, will be forwarded to the same cache server. By 
default, URL hashing is disabled. When enabling this option, the network administrator must 
also specify the number of bytes (up to 255) to be used for hashing the URL. 

The applications of URL hashing for WCR and SLB are described below. 

URL Hashing for Web Cache Redirection 

Using the hashing algorithm, you can optimize “cache hits,” redirecting client requests going 
to the same page of an origin server to a specific cache server. 

■ The load-balancing algorithm must be configured to be hash or minmiss. 

■ Hashing is based on the URL, including the HTTP Host header (if present), up to a maxi¬ 
mum of 255 bytes. 

Example: The switch will use the string “alteonwebsystems.com/products/180/” for hashing 
the following request: 

GET http://products/180 / HTTP/1.0 
HOST:www.alteonwebsystems.com 

URL Hashing for Server Load Balancing 

The default hashing algorithm for virtual SLB is the IP source address. By enabling URL hash¬ 
ing, requests going to the same page of an origin server will be redirected to the same real 
server or cache server. 

■ The load-balancing algorithm must be configured to be hash or minmiss. 

■ Hashing is based on the URL, including the HTTP Host: header (if present), up to a maxi¬ 
mum of 255 bytes. 
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Virtual Server Load Balancing of Nontransparent Caches 

Customers can deploy a cluster of non-transparent proxy caches and use the virtual server to 
load balance requests to these cache servers. 

The client’s browser will be configured to send Web requests to a nontransparent cache (the IP 
address of the virtual server configured). 

If hash is selected as the load-balancing algorithm, the current hashing algorithm will only use 
the source IP address for hashing in SLB. Thus, the switch may not send Web requests for the 
same origin server to the same proxy cache server. For example, requests made from a client to 
“http://www.alteonwebsystems.com/products” from different clients may get sent to different 
caches. 




Virtual Server IP Address: 
205.178.13.243 


Client's browser is configured 
to send Web requests to the 
origin server via the virtual server 



Non-Transparent 
Cache Farm 


Figure 15-4 Balancing Nontransparent Caches 
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Configuring URL Hashing 

You can direct the same URL request to the same cache or proxy server that uses a virtual 
server IP address to load balance proxy requests. By configuring hash or minmisses as the 
metric, the switch will use the number of bytes into the URI to calculate the hash key. 

If the host field exists and the switch is configured to look into the Host: header, the switch will 
also use the Host: header field to calculate the hash key. 

To configure URL hashing, perform the following procedure: 

1. Before you can configure URL hashing, ensure that the switch has already been config¬ 
ured for basic SLB. Configuration includes the following tasks: 

■ Assign an IP address to each of the real servers in the server pool. 

■ Define an IP interface on the switch. 

■ Define each real server. 

■ Assign servers to real server groups. 

■ Define virtual servers and services. 

For information on how to configure your network for SLB, see Chapter 1. 

2. Enable URL parsing. 

>> # /cfg/slb/virt 1/service 80/httpslb enable urlhash 25 

3. Set the metric for the real server group to minmisses or hash. 

>> # /cfg/slb/group 1/metric hash|minmiss 
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Exclusionary String Matching for URL SLB 


URL-based SLB and WCR can match up to 128 substrings. 

Examples of substrings are 

■ “/product,” matches URL that starts with “/product” 

■ “product,” matches URL that has the string “product” anywhere in the entire URL 

You can assign one or more substring to real servers. When more than one URL substring is 
assigned to a real server, requests matching any substring will be redirected to that real server. 
There is also a special substring known as “any” that matches all content. 

Web OS supports exclusionary substring matching. Using this option, an administrator can 
define a server to accept any requests regardless of the URL, except requests with a specific 
substring. For example, an administrator can define the URL substring to be excluded, assign it 
to a real server, and have the server interpret it as an exclusion instead of an inclusion. 


NOTE — Once exclusionary substring matching is enabled, clients cannot access the URL 
strings that are added to that real server. This means you cannot configure a dedicated server to 
receive a certain string and, at the same time, have it exclude other URL strings. The exclu¬ 
sionary feature is enabled per server, not per string. 


Example: 

substring 1 = cgi 

substring 2 = NOT cgi/form_A 

substring 3 = NOT cgi/form_B 

When these substrings are assigned to a real server, the behavior is to match all cgi scripts but 
exclude form_Aand form_B. 
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Configuring Exclusionary URL Substring Matching 

To configure exclusionary URL substring matching, perform the following procedure: 

1. Before you can configure URL substring matching, ensure that the switch has already 
been configured for basic SLB. Configuration includes the following tasks: 

■ Assign an IP address to each of the real servers in the server pool. 

■ Define an IP interface on the switch. 

■ Define each real server. 

■ Assign servers to real server groups. 

■ Define virtual servers and services. 

For information on how to configure your network for server load balancing, see Chapter 1. 

By default, this feature is disabled. In order to enable it, you must add at least one load balanc¬ 
ing string to the server. 

>> # /cfg/slb/real 1/exclude enable|disable 


Example 1: 


205.178.15.49, enabled, name, 
200000 backup none, inter 10, 
abled, proxy enabled 
handle URL cookie: disabled 
exclusionary string matching: 


weight 1, tmout 10, maxcon 
retry 4, restr 8, remote dis 

enabled 


2 : test 
real ports: 

http: vport http, group 1, httpslb 
URL hashing: disabled 

virtual server: 1, 205.178.15.45, enabled 


This server will handle any requests except requests containing the string “test.” 
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Example 2: 

205.178.15.49, enabled, name, weight 1, tmout 10, maxcon 
200000 

backup none, inter 10, retry 4, restr 8, remote disabled, 
proxy enabled 

handle URL cookie: disabled 
exclusionary string matching: enabled 

2 : test 
3: /images 
4: /product 
real ports: 

http: vport http, group 1, httpslb 
URL hashing: disabled 

virtual server: 1, 205.178.15.45, enabled 

This server will handle any requests except requests contain the string “test” or requests that 
start with “/images” or request start with “/product”. 

Example 3: 

205.178.15.49, enabled, name, weight 1, tmout 10, maxcon 
200000 

backup none, inter 10, retry 4, restr 8, remote disabled, 
proxy enabled 

handle URL cookie: disabled 
exclusionary string matching: enabled 

1 : any 
real ports: 

http: vport http, group 1, httpslb 
URL hashing: disabled 

virtual server: 1, 205.178.15.45, enabled 
This server will handle no requests, which is the same as disabling this server! 
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Regular Expression Matching 


Overview 

Regular expression matching is a feature of Web OS Layer 7 SLB. Regular expressions are 
used to describe patterns for string matching. It enables the user to use the exact string match¬ 
ing, such as URLs, host names, or IP addresses. It is a powerful and effective way to express 
complex rules for Layer 7 string matching. Both Layer 7 HTTP SLB and Web Cache Redirec¬ 
tion can use regular expressions as a resource. Supporting regular expressions can enhance 
content-based switching in the following areas: 

■ HTTP header matching 

■ URL path portion matching 

Standard Regular Expression Characters 

The following is a list of standard regular expression special characters that are supported in 
the Web OS 9.0 : 


Table 3 Standard Regular Expression Special Characters 


Construction 

Description 

* 

Matches any string of zero or more characters 


Matches any single character 

+ 

Matches one or more occurrences of the pattern it follows 

? 

Matches Zero or one occurrences of its followed pattern 

$ 

Matches the end of a line 

\ 

Escape the following special character 

[abc] 

Matches any of the single character inside the bracket 

[ A abc] 

Matches any single character except those inside the bracket 
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Implementation 

■ Supports one layer of parenthesis. 

■ Supports only single “$” (match at end of line) which must appear at the end of the string. 
For example, “abc$*def ’ is not supported. 

■ The size of the user input string must be 40 characters or less. 

■ The size of the regular expression structure after compilation cannot exceed 43 bytes for 
load balancing strings, and 23 bytes for Web Cache Redirection. The size of regular 
expression after compilation varies, based on regular expression characters used in the 
user input string. 

■ Use “/” at the beginning of the regular expression. Otherwise a regular expression will 
have prefixed to it automatically. For example, “html/*\.htm” will appear as 
“*html/*\.htm”. 

■ Incorrectly or ambiguously formated regular expressions will be rejected instantly. For 
example: 

□ where a “+” or “?” follows a special character like the “*” 

□ A single “+” or “?” sign 

□ Unbalanced brackets and parenthesis 

Features 

The regular expression feature is applicable to both URL SLB path strings and URL SLB redi¬ 
rected expression strings. Thus, the regular expression strings can be entered on both 
/cfg/slb/url/lb/add or / cfg/slb/url/lb/redir/add. As a result, both HTTP 
SLB and WCR can use regular expression as the resource. 


NOTE — The more complex the stmcture of the string, the longer it will take for the server to 
load balance the incoming packets. 
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Content Precedence Lookup 


Overview 

The Layer 7 Precedence Lookup feature in Web OS allows the network administrator to give 
precedence to one Layer 7 parameter over another and selectively decide which parameter 
should be analyzed first. There are six options from which to choose: 

Using the Content Precedence Lookup feature, the Web switch can be configured to make 
more flexible content intelligent switching decisions. This feature allows you to combine up to 
two Layer 7 load balancing mechanisms. You can specify which types of Layer 7 content to 
examine, the order in which they are examined, and a logical operator (and or or) for their 
evaluation. 

The following Layer 7 content types can be specified: 

■ URL SLB 

■ HTTP Host 

■ Cookie 

■ Browsers (User agent) 

■ URL hash 

■ Others 

Using these choices in conjunction with the and and or operators, the Web switch can be con¬ 
figured to refine HTTP-based server load balancing multiple times on a single client HTTP 
request in order to bind it to an appropriate server. 

For example, the following types of load balancing could be manufactured using this feature: 

■ Virtual host and/or URL-based load balancing 

■ Cookie persistence and URL-based load balancing 

■ Cookie load balancing and/or URL-based load balancing 

■ Cookie persistence and HTTP SLB together in the same service 

■ Multiple HTTP SLB process type on the same service 
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Possible uses for this feature are shown in the following scenarios: 

■ If the client request is sent without a cookie, and if no HTTP SLB is configured, then the 
switch just binds to the server. 

■ If the client request is sent without a cookie, but HTTP SLB is configured, then the switch 
will do HTTP SLB binding. 

■ If the client request is sent with a cookie, and a real server associated to the cookie is 
found in the local session table, then the cookie will need to stay bound to that real server. 


Requirements 


■ It requires Direct Access Mode (DAM) to be enabled, or proxy IP address must be config¬ 
ured if DAM is disabled. 

■ It requires delayed binding to be enabled. 


Examples 


Using the or and and Operators 


Consider the following network: 


Real Servers 



1 URL: "/gold" 


Host: "www.host.nef 


Host: "www.host.nef 
URL: "/gold" 


Figure 15-5 Content Precedence Lookup Opertators Example 
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■ For content load balancing based on HTTP Host or URL SLB 

The HTTP Host header takes precedence because it is specified first. Since or is the oper¬ 
ator, if there is no Host Header information, the URL string will be examined next. 

□ If a request from a client contains no Host Header but has a URL string (such as 
“/gold”), the request will be load balanced among Server 1 or Server 3. 

□ If a request from a client contains a Host Header, then the request will be load bal¬ 
anced among Server 2 and Server 3. The URL string is ignored because the HTTP 
Host was specified and matched first. 

■ For content load balancing based on HTTP Host and URL SLB 

The HTTP Host header takes precedence because it is specified first. Since and is the 
operator, both a Host Header and URL string are required. If either is not available, the 
request will be dropped. 

□ If a request from a client contains a URL string (such as “/gold”) but not a Host 
Header, it will not be served by any real server. 

□ If a request from a client contains a URL string (such as “/gold”) and Host Header, it 
will be served only by real server 3. 


Assigning Multiple Strings 

Consider an example with the following features: 



Host: www.a.com Host: www.a.com Host: www.a.com Host: www.b.com Host: www.b.com 
URLU.jpg URL: *.jpg URL: *.cgi URLU.jpg URLU.cgi 

Figure 15-6 Content Precedence Lookup Example 

In this example, a company which provides virtual hosting has content for two large custom¬ 
ers. Customer A uses www.a.com as their domain name, and Customer B uses www.b.com. 
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The virtual hosting company has been granted a limited number of public IP addresses and 
wishes to assign them on a very conservative basis. As a result, they advertise a single virtual 
server IP address that includes both customers Web sites. Additionally, the hosting company 
assigns only one service (HTTP port 80) to support the virtual server. 

The virtual hosting company wishes to maintain the flexibility to allow different types of con¬ 
tent to be placed on different servers. To make most efficient use of their server resources, they 
separate their servers into two groups, using their fastest servers to process dynamic content 
(such as .cgi files) and their slower servers to process all static content (such as .jpg files). 

To configure content precedence lookup for this example, the hosting company groups all the 
real servers into one real server group even though different servers provide services for differ¬ 
ent customers and different types of content. In this case, the servers are set up for the follow¬ 
ing purposes: 


Table 4 Real Server Content 


Server 

Customer 

Content 

Server 1 

Customer A 

Static .jpg files 

Server 2 

Customer A 

Static .jpg files 

Server 3 

Customer A 

Dynamic .cgi files 

Server 4 

Customer B 

Static .jpg files 

Server 5 

Customer B 

Dynamic .cgi files 


When a client request is received with www.a.com in the Host Header and .jpg in the URL, the 
request will be load balanced between Server 1 and Server 2. 

To accomplish this configuration, the administrator must assign multiple strings (a Host 
Header string and a URL string) for each real server. 
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Chapter 16 

Persistence 


The Web OS persistence feature ensures that all connections from a specific client session 

reach the same real server, even when Server Load Balancing (SLB) is used. 

The following topics are addressed in this chapter: 

■ “Overview of Persistence” on page 328. This section gives an overview of persistence and 
the different types of persistence methods implemented in Web OS. 

■ “Cookie-Based Persistence” on page 330. The use of cookie persistence provides a mech¬ 
anism for inserting a unique key for each client of a virtual server. This feature is only 
used in nonsecure socket layer (non-SSL) connections. This section discusses in detail 
how persistence is maintained between a client and a real server using different types of 
cookies. 

■ “SSL Session ID-Based Persistence” on page 341. This section explains how an applica¬ 
tion server and client communicate over an encrypted HTTP session. 
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Overview of Persistence 


In a typical SLB environment, traffic comes from various client networks across the Internet to 
the virtual server IP address on the Web switch. The switch then load balances this traffic 
among the available real servers. 

In any authenticated Web-based application, it is necessary to provide a persistent connection 
between a client and the Web server to which it is connected. Because HTTP does not carry 
any state information for these applications, it is important for the browser to be mapped to the 
same real server for each HTTP request until the transaction is complete. This ensures that the 
client traffic is not load balanced mid-session to a different real server, forcing the user to 
restart the entire transaction. 

Persistence-based SLB enables the network administrator to configure the network to redirect 
requests from a client to the same real server that initially handled the request. Persistence is an 
important consideration for administrators of e-commerce Web sites, where a server may have 
data associated with a specific user that is not dynamically shared with other servers at the site. 

In Web OS, persistence can be based on the following characteristics: source IP address, cook¬ 
ies, and Secure Sockets Layer (SSL) session ID. 

Using Source IP Address 

Until recently, the only way to achieve TCP/IP session persistence was to use the source IP 
address as the key identifier. There are two major conditions which cause problems when ses¬ 
sion persistence is based on a packet’s IP source address: 

■ Many clients sharing the same source IP address (proxied clients): Proxied clients 
appear to the switch as a single source IP address and do not take advantage of SLB on the 
switch. When many individual clients behind a firewall use the same proxied source IP 
address, requests are directed to the same server, without the benefit of load balancing the 
traffic across multiple servers. Persistence is supported without the capability of effec¬ 
tively distributing traffic load. 

Also, persistence is broken if you have multiple proxy servers behind the Web switch per¬ 
forming SLB. The Web switch changes the client’s address to different proxy addresses as 
attempts are made to load balance client requests. 

■ Single client sharing a pool of source IP addresses: When individual clients share a 
pool of source IP addresses, persistence for any given request cannot be assured. Although 
each source IP address is directed to a specific server, the source IP address itself is ran¬ 
domly selected, thereby making it impossible to predict which server will receive the 
request. SLB is supported, but without persistence for any given client. 
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Using Cookies 

Cookies are strings passed via HTTP from servers to browsers. Based on the mode of opera¬ 
tion, cookies are inserted by either the Web switch or the server. After a client receives a 
cookie, a server can poll that cookie with a GET command, which allows the querying server 
to positively identify the client as the one that received the cookie earlier. 

The cookie-based persistence feature solves the proxy server problem and gives better load 
distribution at the server site. In the Web switch, cookies are used to route client traffic back to 
the same physical server to maintain session persistence. 

Using SSL Session ID 

The SSL session ID is effective only when the server is running SSL transactions. Because of 
the heavy processing load required to maintain SSL connections most network configurations 
use SSL only when it is necessary. Persistence based on SSL Session ID ensures completion of 
complex transactions in proxy server environments. However, this type of persistence does not 
scale on servers because of their computational requirements. 
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Cookie-Based Persistence 


Cookies are a mechanism for maintaining state between clients and servers. When the server 
receives a client request, the server issues a cookie , or token, to the client, which the client then 
sends to the server on all subsequent requests. Using cookies, the server does not require 
authentication, the client IP address, or any other time-consuming mechanism to determine 
that the user is the same user that sent the original request. 

In the simplest case, the cookie may be just a “customer ID” assigned to the user. It may be a 
token of trust, allowing the user to skip authentication while his or her cookie is valid. It may 
also be a key that associates the user with additional state data that is kept on the server, such as 
a shopping cart and its contents. In a more complex application, the cookie may be encoded so 
that it actually contains more data than just a single key or an identification number. The 
cookie may contain the user’s preferences for a site that allows their pages to be customized. 


USER REGISTERS TO BUY 


WEB SERVER DESIGNATED TO SERVE 
COOKIES RECORDS INFORMATION AND 
SENDS THE CLIENT A COOKIE 


ITEM 





5 COOKIE STORED ON CLIENT 
MACHINE 

4 

SWITCH RECORDS OR REWRITES 

COOKIE INFORMATION BASED ON 
CONFIGURATION 


— 



SWITCH COMPLETES THREE-WAY 
HANDSHAKE WITH CLIENT. 


BASED ON COOKIE INFORMATION SWITCH 

REDIRECTS REQUEST TO THE SAME SERVER 
OR HASHES ON COOKIE VALUE 


FORWARDS HTTP REQUEST TO COOKIE 
SERVER 


Figure 16-1 Cookie-Based Persistence: How It Works 
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The following topics discussing cookie-based persistence are detailed in this section: 

■ “Permanent and Temporary Cookies” on page 331 

■ “Cookie Formats” on page 331 

■ “Cookie Properties” on page 332 

■ “Client Browsers that Do Not Accept Cookies” on page 332 

■ “Cookie Modes of Operation” on page 333 

■ “Configuring Cookie-Based Persistence” on page 336 

Permanent and Temporary Cookies 

Cookies can either be permanent or temporary. A permanent cookie is stored on the client's 
browser, as part of the response from a Web site’s server. It will be sent by the browser when 
the client makes subsequent requests to the same site, even after the browser has been shut 
down. A temporary cookie is only valid for the current browser session. Similar to a SSL Ses¬ 
sion-based ID, the temporary cookie expires when you shut down the browser. Based on RFC 
2109, any cookie without an expiration date is a temporary cookie. 

Cookie Formats 

A cookie can be defined in the HTTP header (the recommended method) or placed in the URL 
for hashing. The cookie is defined as a “Name=Value” pair and can appear along with other 
parameters and cookies. For example, the cookie “SessionID=12 34” can be represented in 
one of the following ways: 

■ In the HTTP Header 

Cookie: SesssionID=1234 

Cookie: ASP_SESSIONID=POIUHKJHLKHD 

Cookie: name=john_smith 

The second cookie represents an Active Server Page (ASP) session ID. The third cookie 
represents an application-specific cookie that records the name of the client. 

■ Within the URL 

http://www.mysite.com/reservations/SessionID=1234 
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Cookie Properties 

Cookies are configured on the Web switch by defining the following properties: 

■ Cookie names of up to 20 bytes 

■ The offset of the cookie value within the cookie string 

For security, the real cookie value can be embedded somewhere within a longer string. 
The offset directs the Web switch to the starting point of the real cookie value within the 
longer cookie string. 

■ Length of the cookie value 

This defines the number of bytes to extract for the cookie value within a longer cookie 
string. 

■ Whether to find the cookie value in the HTTP header (the default) or the URL 

■ Cookie values of up to 64 bytes for hashing 

Hashing on cookie values is used only with the passive cookie mode (“Passive Cookie 
Mode” on page 334), using a temporary cookie. The switch mathematically calculates the 
cookie value using a hash algorithm to determine which real server should receive the 
request. 

■ An asterisk (*) in cookie names for wildcards 
For example. Cookie name = ASPsession* 

Client Browsers that Do Not Accept Cookies 

Under normal conditions, most browsers are configured to accept cookies. However, if a client 
browser is not configured to accept cookies, you must use hash as the load-balancing metric 
to maintain session persistence. 

With cookie-based persistence enabled, session persistence for browsers that do not accept 
cookies will be based on the source IP address. However, individual client requests coming 
from a proxy firewall will appear to be coming from the same source IP address. Therefore, the 
requests will be directed to a single server, resulting in traffic being concentrated on a single 
real server instead of load balanced across the available real servers. 
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Cookie Modes of Operation 

Web OS supports the following modes of operation for cookie-based session persistence: 
insert, passive, and rewrite mode. The following table shows the differences among the modes: 


Table 16-1 Comparison Among the Three Cookie Modes 


Cookie Mode 

Configuration Required 

Cookie Location 

Uses Switch 
Session Entry 

Insert Cookie 

Switch only 

HTTP Header 

No 

Passive Cookie 

Server and Switch 

HTTP Header or URL 

Yes 

Rewrite Cookie 

Server and Switch 

HTTP Header 

No 


Each of the modes are explained in detail in the following sections. 


Insert Cookie Mode 

In the insert cookie mode, the Web switch generates the cookie value on behalf of the server. 
Because no cookies are configured at the server, the need to install cookie server software on 
each real server is eliminated. 


In this mode, the client sends a request to visit the Web site. The Web switch performs load 
balancing and selects a real server. The real server responds without a cookie. The Web switch 
inserts a cookie and forwards the new request with the cookie to the client. 

1. Configure switch to insert cookie values 


2. Client visits the Web site via HTTP request 


3. Switch selects 
server via SLB 


Client 


R t£- 

1 


Internet 


Proxy Firewall 

5. Web switch inserts a cookie and forwards the 
response to the client. 


Web Switch 


Web Server 
Farm 


4. Server responds 
without any cookie 


Figure 16-2 Insert Cookie Mode 
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Passive Cookie Mode 

In Passive Cookie mode, when the client first makes a request, the switch selects the server 
based on the load-balancing metric. The real server embeds a cookie in its response to the cli¬ 
ent. The switch records the cookie value and matches it in subsequent requests from the same 
client. 


NOTE — The passive cookie mode is recommended for temporary cookies. However, you can 
use this mode for permanent cookies if the server is embedding an IP address. 


The following figure shows passive cookie mode operation: 


1. Configure server to send cookies 

2. Configure switch to record cookie values 



6. Switch registers cookie value and forwards it 
to the client for use in subsequent requests 


5. Server returns 
cookie value 


Figure 16-3 Passive Cookie Mode 

Subsequent requests from Client 1 with the same cookie value will be sent to the same real 
server (RIP 1 in this example). 


Rewrite Cookie Mode 

In rewrite cookie mode, the Web switch generates the cookie value on behalf of the server, 
eliminating the need for the server to generate cookies for each client. 

Instead, the server is configured to return a special persistence cookie which the switch is con¬ 
figured to recognize. The switch then intercepts this persistence cookie and rewrites the value 
to include server-specific information before sending it on to the client. Subsequent requests 
from the same client with the same cookie value are sent to the same real server. 

Rewrite cookie mode requires at least eight bytes in the cookie header. An additional eight 
bytes must be reserved if you are using cookie-based persistence with Global Server Load Bal¬ 
ancing (GSLB). 
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NOTE — Rewrite cookie mode only works for cookies defined in the HTTP header, not cookies 
defined in the URL. 


Example: The following figure shows rewrite cookie mode operation: 

1. Configure switch to rewrite cookie values 


Client 


2. Client visits the Web site via HTTP request 


Internet 


3. Switch selects 
server via SLB 




Proxy Firewall 



Web Switch 


5. Web switch rewrites the cookie to contain a 
server ID for hashing on subsequent requests 



Web Server 
Farm 


4. Server HTTP response 
includes empty cookie 


Figure 16-4 Rewrite Cookie Mode 


NOTE — When the Web switch rewrites the value of the cookie, the rewritten value represents 
the responding server; that is, the value can be used for hashing into a real server ID or it can 
be the real server IP address. The rewritten cookie value is encoded. 
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Configuring Cookie-Based Persistence 

1. Before you can configure cookie-based persistence, you need to configure the switch for 
basic SLB. This includes the following tasks: 

■ Assign an IP address to each of the real servers in the server pool. 

■ Define an IP interface on the switch. 

■ Configure each real server with its IP address, name, weight, and so forth. 

■ Assign servers to real server groups. 

■ Define virtual servers and services. 

For information see “Server Load Balancing” on page 67. 

2. Either enable Direct Access Mode (DAM), or disable DAM and specify proxy IP 
address(es) on the client port(s). 

■ Enable DAM for the switch. 

>> # /cfg/slb/adv/direct ena (Enable Direct Access Mode on switch) 


■ Disable DAM and specify proxy IP address(es) on the client port(s). 


» # 

/cfg/slb/adv/direct disable 

(Disable DAM on the switch) 

» # 

/cfg/slb/port 1 

(Select network port 1) 

» # 

pip 200.200.200.68 

(Set proxy IP address for port 1) 


NOTE — If Virtual Matrix Architecture (VMA) is enabled on the switch, you must configure a 
unique proxy IP address for every port (except port 9). 


3. If proxy IP addresses are used, make sure server processing is disabled on the server 
port. 


» # /cfg/slb/port 1 

(Select switch port 1) 

>> # server dis 

(Disable sen’er processing on port 1) 
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4. Select the appropriate load-balancing metric for the real server group. 


>> # /cfg/slb/group 2/metric hash 


(Select hash as ser\>er group metric) 


■ If embedding an IP address in the cookie, select roundrobin or leastconns as the 
metric. 

■ If you are not embedding the IP address in the cookie, select hash as the metric in con¬ 
junction with a cookie assignment server. 

While you may experience traffic concentration using the hash metric with a cookie 
assignment server, using a hash metric without a cookie assignment server will cause 
traffic concentration on your real servers. 

5. Enable cookie-based persistence on the virtual server service. 

In this example, cookie-based persistence is enabled for service 80 (HTTP). 


>> # /cfg/slb/virt 1/service 80/pbind 

Current persistent binding mode: disabled 

Enter cookie|sslid|disable persistence mode: cookie 


Once you specify cookie as the mode of persistence, you will be prompted for the following 
parameters: 


Enter insert|passive I rewrite cookie persistence mode [i/p/r] : p 
Enter cookie name: CookieSessionl 

Enter starting point of cookie value [1-64]: 1 
Enter number of bytes to extract [0-64] : 8 
Look for cookie in URI [e|d]: d 
Set multiple response count [1-16]: 1 


■ Cookie-based persistence mode: insert, passive or rewrite 

■ Cookie name 

■ Starting point of the cookie value 

■ Number of bytes to be extracted 

■ Look for cookie in the URI [e I d] 

If you want to look for cookie name/value pair in the URI, enter e to enable this option. To 
look for the cookie in the HTTP header, enter d to disable this option. 

■ Set multiple response count 
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This parameter is set for passive mode only. Typically, the Web switch searches the first 
HTTP response packet from the server and, if a persistence cookie is found, sets up a per¬ 
sistence connection between the server and the client. While this approach works for most 
servers, some customers with complex server configurations might send the persistence 
cookie a few responses later. In order to achieve cookie-based persistence in such cases, 
Web OS allows the network administrator to configure the switch to look through multiple 
HTTP responses from the server. The switch looks for the persistence cookie in the speci¬ 
fied number of responses (each of them can be multi-frame) from the server. 

Example 1: Setting the Cookie Location 

In this example, the client request has two different cookies labeled “UID.” One exists in the 
HTTP header and the other appears in the URI: 

GET /product/switch/UID=12345678; ck=12 34... 

Host: www.alteonwebsystems.com 
Cookie: UID=87654321 

■ Look for the cookie in the HTTP header 


» # /cfg/slb/virt 1/service 80/pbind cookie passive UID 1 8 dis 


The last parameter in this command answers the “Look for cookie in URI?” 
prompt. If you set this parameter to disable, the Web switch will use UID=87 654321 
as the cookie. 

■ Look for the cookie in the URI 


>> # /cfg/slb/virt 1/service 80/pbind cookie passive UID 1 8 ena 


The last “Look for cookie in URI?” parameter is set to enable. Therefor the Web switch 
will use UID=12345678 as the cookie. 


338 ■ Chapter 16: Persistence 


Alteon ((^Systems 

050159A, May 2001 




Web OS 9.0 Application Guide 


Example 2: Parsing the Cookie 

This example shows three configurations where the switch uses the hashing key or wild cards 
to determine which part of the cookie value should be used for determining the real server. For 
example, the value of the cookie is defined as follows: 

Cookie: sid=0123456789abcdef; namel=valuel;... 

■ Select the entire value of the s id cookie as a hashing key for selecting the real server: 

>> # /cfg/slb/virt 1/service 80/pbind cookie passive sid 1 16 dis 


This command directs the switch to use the sid cookie, starting with the first byte in the 
value and using the full 16 bytes. 

■ Select a specific portion of the sid cookie as a hashing key for selecting the real server: 


>> # /cfg/slb/virt 1/service 80/pbind cookie passive sid 8 4 dis 


This command directs the switch to use the sid cookie, starting with the eight byte in the 
value and using only four bytes. This uses 7 8 9a as a hashing key. 

■ Using wildcards for selecting cookie names: 


>> # /cfg/slb/virt 1/service 80/pbind cookie passive 
ASPSESSIONID* 1 16 dis 


With this configuration, the switch will look for a cookie name that starts with ASPSES¬ 
SIONID. ASPSESSIONID 123, ASPSESSIONID45 6, and ASPSESSIONID7 8 9 will 
all be seen by the switch as the same cookie name. If more than one cookie matches, only 
the first one will be used. 

Example 3: Using Passive Cookie Mode 

If you are using passive cookie mode, the Web switch examines the server’s Set-Cookie : 
value and directs all subsequent connections to the server that assigned the cookie. 

For example, if Server 1 sets the cookie as “Set-Cookie : sid=12345678,” then all traf¬ 
fic from a particular client with cookie sid= 12345678 will be directed to Server 1. 

The following command is used on the Web switch: 


» # /cfg/slb/virt 1/service 80/pbind cookie passive sid 1 8 dis 
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Example 4: Using Rewrite Cookie Mode 

■ Rewrite server cookie with the encrypted real server IP address: 

In cookie rewrite mode, if the cookie length parameter is configured to be eight bytes, the 
switch will rewrite the placeholder cookie value with the encrypted real server IP address. 

» # /cfg/slb/virt 1/service 80/pbind cookie rewrite sid 1 8 dis 

If the server is configured to include a placeholder cookie, such as follows: 

Set-Cookie: sid=alteonpersistence; 

then the Web switch will rewrite the first eight bytes of the cookie to include the server’s 
encrypted IP address: 

Set-Cookie: sid=cdb20f04rsistence; 

All subsequent traffic from a specific client with this cookie will be directed to the same 
real server. 

■ Rewrite server cookie with the encrypted real server IP address and virtual server IP 
address: 

If the cookie length is configured to be 16 bytes, the switch will rewrite the cookie value 
with the encrypted real server IP address and virtual server IP address. 

» # /cfg/slb/virt 1/service 80/pbind cookie rewrite sid 1 16 dis 

If the server is configured to include a placeholder cookie, as follows: 

Set-Cookie: sid=alteonwebcookies; 

then the Web switch will rewrite the first 16 bytes of the cookie to include the encrypted 
real server IP address and virtual server IP address: 

Set-Cookie: sid=cdb20f04cdb20f0a; 

All subsequent traffic from a specific client to the particular virtual server IP address with 
this cookie will be directed to the same real server. 
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SSL Session ID-Based Persistence 


SSL is a set of protocols built on top of TCP/IP that allows an application server and client to 
communicate over an encrypted HTTP session, providing authentication, non-repudiation, and 
security. The SSL protocol handshake is performed using clear (unencrypted) text. The content 
data is then encrypted (using an algorithm exchanged during the handshake) prior to being 
transmitted. 

Using the SSL session ID, the switch forwards the client request to the same real server to 
which it was bound during the last session. Because SSL protocol allows many TCP connec¬ 
tions to use the same session ID from the same client to a server, key exchange needs to be 
done only when the session ID expires. This reduces server overhead and provides a mecha¬ 
nism, even when the client IP address changes, to send all sessions to the same real server. 


NOTE — The destination port number to monitor for SSL traffic is user-configurable. 


How SSL Session ID-Based Persistence Works 

■ All SSL sessions that present the same session ID (32 random bytes chosen by the SSL 
server) will be directed to the same real server. 


NOTE - The SSL session ID can only be read by the switch after the TCP three-way hand¬ 
shake. In order to make a forwarding decision, the switch must terminate the TCP connection 
to examine the request. 


■ New sessions are sent to the real server based on the metric selected (hash, 
roundrobin, leastconns, minmisses, response, and bandwidth). 

■ If no session ID is presented by the client, the switch picks a real server based on the met¬ 
ric for the real server group and waits until a connection is established with the real server 
and a session ID is received. 

■ The session ID is stored in a session hash table. Subsequent connections with the same 
session ID are sent to the same real server. This binding is preserved even if the server 
changes the session ID mid-stream. A change of session ID in the SSL protocol will cause 
a full three-way handshake to occur. 

■ Session IDs are kept on the switch until an idle time equal to the configured server time¬ 
out (a default of 10 minutes) for the selected real server has expired. 

Figure 16-5 illustrates persistence based on SSL session ID as follows: 
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1. An SSL Hello handshake occurs between Client 1 and Server 1 via the Web switch. 

2. An SSL session ID is assigned to Client 1 by Server 1. 

3. The Web switch records the SSL session ID. 

4. The Web switch selects a real server based on the existing SLB settings. 

As a result, subsequent connections from Client 1 with the same SSL session ID are directed to 
Server 1. 


Web Server 
Farm 



5. Client 2 appears to the switch to have the same source IP address as Client 1 because they 
share the same proxy firewall. 

However, the Web switch does not automatically direct Client 2 traffic to Server 1 based on the 
source IP address. Instead an SSL session ID for the new traffic is assigned. Based on SLB set¬ 
tings, the connection from Client 2 is spliced to Server 3. 

As a result, subsequent connections from Client 2 with the same SSL session ID are directed to 
Server 3. 
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Configuring SSL Session ID-Based Persistence 

To configure session ID-based persistence for a real server, perform the following steps: 

1. Configure real servers and services for basic SLB, as indicated below: 

■ Define each real server and assign an IP address to each real server in the server pool. 

■ Define a real server group and set up health checks for the group. 

■ Define a virtual server on the virtual port for HTTPS (for example, port 443) and assign a 
real server group to service it. 

■ Enable SLB on the switch. 

■ Enable client processing on the port connected to the client. 

For information on how to configure your network for SLB, see “Server Load Balancing” on 
page 67 

2. If a proxy IP address is not configured on the client port, enable DAM for real servers. 

» # /cfg/slb/adv/direct ena 

3. Select session ID-based persistence as the persistent binding option for the virtual port. 

>> # /cfg/slb/virt <virtucil server number>/ service <virtualport> pbind sslid 

4. Enable client processing on the client port. 

» # /cfg/slb/port <port number>/c lient ena 
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Chapter 17 

Bandwidth Management 


Bandwidth Management (BWM) enables Web site managers to allocate a certain portion of the 
available bandwidth for specific users or applications. It allows companies to guarantee that 
critical business traffic, such as e-commerce transactions, receive higher priority versus non- 
critical traffic. Traffic classification can be based on user or application information. BWM 
policies can be configured to set lower and upper bounds on the bandwidth allocation. 


Overview 


To manage bandwidth, create one or more bandwidth management contracts. The switch uses 
these contracts to limit individual traffic flows. 



2. Administrator configures 
bandwidth policy and contract 


5. TOS value (optional) affects router 
bandwidth 


3. Classification is done on 
ingress port of switch 


User buys a contract 
example, a VIP address) 


4. Bandwidth Management done on egress 
port of switch 

- Can optionally set TOS values to reflect 
usage rate 


BANDWIDTH 


1 . 

(For 



Figure 17-1 Bandwidth Management: How It Works 
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Each contract comprises the following: 

■ A classification policy where certain frames are grouped together 

■ A bandwidth policy specifying usage limitations to be applied to these frames 


NOTE — At any given time, up to 256 BWM contracts can be configured for a single Alteon 
AD3 or Alteon 180e Web switch. Up to 1024 contracts can be created for a single Alteon AD4 
or Alteon 184 Web switch. 


■ When Virtual Matrix Architecture (VMA) is not enabled, bandwidth classification is done 
on the ingress side of the switch (at the ingress port or designated port) and can be based 
on the following: source port, VLAN, filters. Virtual Internet Protocol (VIP) address, ser¬ 
vice on the Virtual server, URL, and so on. 

When VMA is enabled, traffic classification that is not based on filters or Server Load 
Balancing (SLB) is done on the ingress port —that is, the port on which the frame is 
received (not the client port or the server port). If the traffic classification is filter-based or 
SLB traffic, then the classification occurs on the designated port. 


Note - VMA is recommended when Bandwidth Management is enabled. 


■ Bandwidth management occurs on the egress port of the switch—that is, the port from 
which the frame is leaving. However, in the case of multiple routes or trunk groups, the 
egress port can actually be one of several ports (from the point-of-view of where the 
queues are located). 

Rate management is controlled by using queues for each contract and by scheduling when 
frames are sent from each queue. Each frame is put into a managed buffer and placed on a 
contract queue. The time that the next frame is supposed to be transmitted for the contract 
queue is calculated according to the configured rate of the contract, the current egress rate 
of the ports, and the buffer size set for the contract queue. The scheduler then organizes all 
the frames to be sent according to their time-based ordering and meters them out to the 
port. 
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Bandwidth Policies 


Bandwidth policies are bandwidth limitations defined for any set of frames, specifying the 
guaranteed bandwidth rates. A bandwidth policy is often based on a rate structure whereby a 
Web host or co-location provider could charge a customer for bandwidth utilization. There are 
three rates that are configured: a Committed Information Rate (CIR)/Reserved Limit, a Soft 
Limit, and a Hard Limit, as described below. 


A queue depth is also associated with a policy. A queue depth is the size of the queue that holds 
the data. It can be adjusted to accommodate delay-sensitive traffic (such as audio) versus drop- 
sensitive traffic (such as FTP). 



Hard Limit 


Soft Limit 



Reserved Limit 


Figure 17-2 Bandwidth Rate Limits 
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Rate Limits 

A bandwidth policy specifies three limits, listed and described in Table 17-1: 


Table 17-1 Bandwidth Rate Limits 


Rate Limit 

Description 

Committed Information 
Rate (CIR) 
or Reserved Limit 

This is a rate that a bandwidth classification is always guaranteed. In con¬ 
figuring BWM contracts, ensure that the sum of all committed informa¬ 
tion rates never exceeds the link speeds associated with ports on which 
the traffic is transmitted. In a case where the total CIRs exceed the out¬ 
bound port bandwidth, the switch will perform a graceful degradation of 
all traffic on the associated ports. 

Soft Limit 

This is the desired bandwidth rate, that is, the rate the customer has 
agreed to pay on a regular basis. When output bandwidth is available, a 
bandwidth class will be allowed to send data at this rate. No exceptional 
condition will be reported when the data rate does not exceed this limit. 

Hard Limit 

This is a “never exceed” rate. A bandwidth class is never allowed to trans¬ 
mit above this rate. Typically, traffic bursts between the soft limit and the 
hard limit are charged a premium. The maximum hard limit for a band¬ 
width policy is 1 Gbps, even when multiple Gigabit ports are trunked. 


Bandwidth Policy Configuration 

Each bandwidth policy, comprised of the reserved, soft, and hard limits, is assigned an index. 
These policies can be found under the /cfg/bwm menu. Up to 64 bandwidth policies can be 
defined. Bandwidth limits are usually entered in Mbps. 


NOTE — For better granularity, rates can be entered in Kbps by appending “K” to the entered 
number. For example, 1 Mbps can be entered as either “1” or as “1024k.” 


Table 17-2 lists the granularity of policy limits: 


Table 17-2 Bandwidth Policy Limits 


Bandwidth Range 

Interval 

Bandwidth Range 

Interval 

250 Kbps to 5000 Kbps 

250 Kbps 

50 Mbps to 150 Mbps 

10 Kbps 

1 Mbps to 20 Mbps 

1 Mbps 

150 Mbps to 500 Mbps 

25 Mbps 

20 Mbps to 50 Mbps 

5 Mbps 

500 Mbps to 1000 Mbps 

50 Mbps 


In addition, a queue size is associated with each policy. The queue size is measured in bytes. 
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Data Pacing 


The mechanism used to keep the individual traffic flows under control is called data pacing. It 
is based on the concept of a virtual clock and theoretical departure times (TDT). The actual cal¬ 
culation of the TDT is based initially on the soft limit rate. The soft limit can be thought of as a 
target limit for the ISP’s customer. So long as bandwidth is available and the classification 
queue is not being filled at a rate greater than the soft limit, the TDT will be met for both incom¬ 
ing frames and outgoing frames and no borrowing or bandwidth limitation will be necessary. 

Queue 1 —|-1—|- 

Queue 2 -1- -|- 

Queue 3 — 1-| - 

Queue 4 _|_j_|_j_|^_|_j_ 

Time -► 

Figure 17-3 Virtual Clocks and TDT 

If the data is arriving more quickly than it can be transmitted at the soft limit and sufficient 
bandwidth is still available, the rate is adjusted upwards based on the depth of the queue, until 
the rate is fast enough to reduce the queue depth or the hard limit is reached. If the data cannot 
be transmitted at the soft limit, then the rate is adjusted downward until the data can be trans¬ 
mitted or the CIR is hit. If the CIR is overcommitted among all the contracts configured for the 
switch, graceful degradation will reduce each CIR until the total bandwidth allocated fits 
within the total bandwidth available. 

Each BWM contract is assigned a bandwidth policy index and (optionally) a name. This index 
can be viewed using the /cfg/bwm/cont menu. Contracts can be enabled and disabled. The 
set of classifications associated with each contract can be viewed using the / inf o/bwm menu. 

For frames qualifying for multiple classifications, precedence of contracts is also specified per 
contract. If no precedence is specified, the default order is used (see “Precedence” on page 351). 

■ When both filter Types-Of-Service (TOS) and BWM TOS are applied, BWM TOS has 
precedence. 

■ BWM configurations will optionally be synchronized during VRRP synchronization 
except the port contracts and VLAN contracts, which will not be synchronized. 
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Classification Criteria 


The frames associated with a particular BWM contract are specified, using the parameters 
listed below. All of these classifications are aimed at limiting the traffic outbound from the 
server farm for bandwidth measurement and control. 

Server Output Bandwidth Control 

■ Physical Port - All frames are from a specified physical port. 

■ VLAN - All frames are from a specified VLAN. Even if a VLAN translation occurs, the 
bandwidth policy is based on the ingress VLAN. 

■ IP Source Address - All frames have a specified IP source address or range of addresses 
defined with a subnet mask. 

■ IP Destination Address - All frames have a specified IP destination address or range of 
addresses defined with a subnet mask. 

■ Switch services on the virtual servers 

The following are various Layer 4 groupings: 

□ A single virtual server 

□ A group of virtual servers 

□ A service for a particular virtual server 

□ Select a particular port number (service on the virtual server) within a particular vir¬ 
tual server IP address. 

The following are various Layer 7 groupings: 

□ A single URL path 

□ A group of URL paths 

□ A single cookie 

Application Bandwidth Control 

Classification policies allow bandwidth limitations to be applied to particular applications; that 
is, they allow applications to be identified and grouped. Classification can be based on any fil¬ 
tering rule, including those listed below: 

■ TCP Port Number - All frames with a specific TCP source or destination port number 

■ UDP - All UDP frames 

■ UDP Port Number - All frames with a specific UDP source or destination port number 
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Combinations 

Combinations of classifications are limited to grouping items together into a contract. For 
example, if you wanted to have three different virtual servers associated with a contract, you 
would specify the same contract index on each of the three virtual server IP addresses. You can 
also combine filters in this manner. 

Precedence 

If a frame qualifies for different classifications, it is important to be able to specify the classifi¬ 
cation with which it should be associated. There are two mechanisms to address classifica¬ 
tion—a per-contract precedence value and a default ordering. If a contract does not have an 
assigned precedence value, then the ordering is as follows: 

1. Layer 7 applications (for example, URL, HTTP, headers, cookies, and so forth) 

2. Layer 4 services on the virtual server 

3. Filter 

4. VLAN 

5. Source Port/Default Assignment 

Bandwidth Classification Configuration 

Any item that is configured with a filter can be used for BWM. Bandwidth classification is per¬ 
formed using the following menus: 

■ /cfg/slb/filt is used to configure classifications based on the IP destination 
address, IP source address, TCP port number, UDP, UDP port number, or any filter rule. 

■ /cfg/slb/virt is used to configure classifications based on virtual servers. 

■ /cf g/port is used to configure classifications based on physical ports. 

(In case of trunking, use /cf g/trunk.) 

■ /cfg/vlan is used to configure classifications based on VLANs. 

■ /cfg/slb/url/lb is used to configure classification based on URL paths. 

To associate a particular classification with a contract, enter the contract index into the “cont” 
menu option under the applicable configuration menus. 
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Frame Discard 

When packets in a contract queue have not yet been sent and the buffer size set for the queue is 
full, any new frames attempting to be placed in the queue will be discarded. 

URL-Based Bandwidth Management 

URL-based BWM allows the network administrator or Web site manager to control bandwidth 
based on URLs, HTTP headers, or cookies. 

All three types of BWM are accomplished by following the configuration guidelines on con¬ 
tent switching described in Chapter 15, “Content Intelligent Switching.” You would also need 
to assign a contract to each defined string, where the string is contained in a URL, an HTTP 
header, or a cookie. 

BWM based on URLs gives Web site managers the following capabilities: 

■ Ability to allocate bandwidth based on the type of request 

The switch allocates bandwidth based on certain strings in the incoming URL request. For 
example, as shown in Figure 17-4, if a Web site has lOMbs of bandwidth, the site manager 
can allocate 1 Mbs of bandwidth for static HTML content, 3Mbs of bandwidth for graphic 
content and 4Mbs of bandwidth for dynamic transactions, such as URLs with cgi-bin 
requests and . asp requests. 

■ Ability to prioritize transactions or applications 

By allocating bandwidth, the Web switch can guarantee that certain applications and trans¬ 
actions get better response time. 

■ Ability to allocate a certain amount of bandwidth for requests that can be cached 

As shown in Figure 17-5 on page 353, users will be able to allocate a certain percentage of 
bandwidth for Web cache requests by using the URL parsing and bandwidth management 
feature. 
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Figure 17-4 URL-Based Bandwidth Management 
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Figure 17-5 URL-Based Bandwidth Management with Web Cache Redirection 


Alteon Web Systems 

050159A, May 2001 


Chapter 17: Bandwidth Management ■ 353 












Web OS 9.0 Application Guide 


HTTP Header-Based Bandwidth Management 


HTTP header-based BWM allows Web site managers to allocate bandwidth based on header 
value. Thus, they can allocate bandwidth based on browser type, cookie value, and so forth. 


Cookie-Based Bandwidth Management 


Cookie-based BWM enables Web site managers to prevent network abuse by bandwidth-hog¬ 
ging users. Using this feature, bandwidth can be allocated by type of user or other user-specific 
information available in the cookie. 

Cookie-based bandwidth management empowers service providers to create tiered services. 
For example, Web site managers can classify users as first class, business class, and coach and 
allocate a larger share of the bandwidth for preferred classes. 



For VIP 172.17.1.1 
First = 2 Mbs 
Business — 1 Mbs 



Client #2 


Figure 17-6 Cookie-Based Bandwidth Management 


NOTE — Cookie-based BWM does not apply to cookie-based persistency or cookie pas¬ 
sive/active mode applications. 
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Bandwidth Statistics and History 


Statistics are maintained in order to allow Web switch owners to bill for bandwidth usage. Sta¬ 
tistics for frequency and count are configurable. Statistics are kept in the individual Switch 
Processors (SP) and then collected every second by the MP (Management Processor). The MP 
then combines the statistics, as statistics for some classifications may be spread across multiple 
SPs. 

The MP maintains some global statistics, such as total octets and a window of historical statis¬ 
tics. When the history buffer of 128K is ready to overflow, it can be optionally e-mailed to a 
user for long-term storage. Additionally, the history buffer can be sent to the user when the 
user enters the command: /oper/bwm/sndhist. The SMTP protocol is used for this 
transfer if the SMTP host has been configured (/cf g/sys/smtp) and the user e-mail address 
has been set up (/cf g/bwm/user). To obtain graphs, the data must be collected and pro¬ 
cessed by an external entity through SNMP or through e-mailed logs. 

History is maintained only for the contracts for which the history option is enabled 

(/cfg/bwm/cont x/hist). 

If SMTP is enabled, then the info command (/info/bwm) can display when the history sta¬ 
tistics will be e-mailed to a user. 

Statistics Maintained 

The total number of octets sent, octet discards, and times over the soft limit are kept for each 
contract. The history buffer maintains the average queue size for the time interval and the aver¬ 
age rate for the interval. 

Statistics and Management Information Bases 

■ For existing BWM classes: 

As mentioned above, the MP maintains per-contract rate usage statistics. These are obtain¬ 
able via a private MIB. 

■ When BWM services are not enabled: 

Even when BWM is not enforced, the MP can still collect classification information and 
report it, allowing the customer to observe a network for a while before deciding how to 
configure it. This feature can be disabled using /cfg/bwm/force dis. When this 
command is used, no limits will be applied on any contract. 
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Packet Coloring (TOS bits) for Burst Limit 


Whenever the soft limit is exceeded, optional packet coloring can be done to allow down¬ 
stream routers to use dijf-serv mechanisms (that is, writing the Type-Of-Service (TOS) byte of 
the IP header) to delay or discard these out-of-profile frames. Frames that are not out-of -pro¬ 
file are marked with a different, higher priority value. This feature can be enabled or disabled 
on a per-contract basis, using the wtos option under the contract menu (/cfg/bwm/cont 
jr/wtos) to enable/disable overwriting IP TOS. 

The actual values used by the switch for overwriting TOS values (depending on whether traffic 
is over or under the soft TOS limit) are set in the bandwidth policy menu (/cf g/bwm/pol 
x ) with the utos and otos options. The values allowed are 0-255. Typically, the values spec¬ 
ified should match the appropriate dif f-serv specification but could be different, depend¬ 
ing on the customer environment. 

Operational Keys 


There are two operational keys for BWM: a standard key and a demo key. The demo key auto¬ 
matically expires after a demo time period. These keys may only be enabled if Layer 4 services 
have been enabled. 
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Configuring Bandwidth Management 


The following procedure provides general instructions for configuring BWM on the switch. 
Specific configuration examples begin on page 360. 

1. Configure the switch as you normally would for SLB. Configuration includes the follow¬ 
ing tasks: 

■ Assign an IP address to each of the real servers in the server pool. 

■ Define an IP interface on the switch. 

■ Define each real server. 

■ Define a real server group. 

■ Define a virtual server. 

■ Define the port configuration. 

For more information about SLB configuration, see “Server Load Balancing” on page 67. 

2. Enable BWM on the switch. 


NOTE — If you purchased the Bandwidth Management option, make sure you enable it by typ¬ 
ing / oper/swkey and entering its software key. 


» # /cfg/bwm/on 

(Turn BWM on) 

Select a bandwidth policy. 


Each policy must have a unique number from 1 to 64. 


» Bandwidth Management# pol 1 

(Select bandwidth policy 1) 


4. Set the hard, soft, and reserved rate limits for the policy, in Mbps. 

Typically, charges are applied for burst rates between the soft and hard limit. Each limit must 
be set between 256K-1000M. 


NOTE — For rates less than 1 Mbps, append a “K” suffix to the number. 


» 

Policy 

1# 

hard 

6 

(Set “never exceed” rate) 

» 

Policy 

1# 

soft 

5 

(Set desired bandwidth rate) 

» 

Policy 

1# 

resv 

4 

(Set committed information rate) 
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5. (Optional) Set the TOS byte value, between 0-255, for the policy underlimit and over¬ 
limit. 

There are two parameters for specifying the TOS bits: underlimit (utos) and overlimit 
(otos). These TOS values are used to overwrite the TOS values of IP packets if the traffic for 
a contract is under or over the soft limit, respectively. These values only have significance to a 
contract if TOS overwrite is enabled in the Bandwidth Management Contract Menu 

(cfg/bwm/cont x/wtos ena.) 

The administrator has to be very careful in selecting the TOS values because of their greater 
impact on the downstream routers. 


>> Policy 1# utos 204 

(Set BWM policy underlimit) 

>> Policy 1# otos 192 

(Set BWM policy overlimit) 


6. Set the buffer limit for the policy. 

Set a value between 8192-128000 bytes. The buffer depth for a BWM contract should be set to 
a multiple of the packet size. 

NOTE — Keep in mind that the total buffer limit for the Bandwidth Management policy is 
128K. 


>> Policy 1# buffer 16320 (Set BWM policy buffer limit) 

7. On the switch, select a BWM contract and (optional) a name for the contract. 

Each contract must have a unique number from 1 to 256. 

>> Policy 1# /cfg/bwm/cont 1 (Select BWM contract 1) 

» BWM Contract 1# name BigCorp (Assign contract name "BigCorp”) 


8. (Optional) Set a precedence value for the BWM contract. 

Each contract can be given a precedence value from 1-256. The higher the number, the higher 
the precedence. If a frame is applicable to different classifications, then the contract with 
higher precedence will be assigned to the frame. If the precedence is the same for the applica¬ 
ble contracts, then the following order will be used to assign the contract to the frame: 

(1) Incoming port, (2) VLAN, (3) Filter, (4) Service on the Virtual server, (5) URL/Cookie 


>> BWM Contract 1# prec 1 


(Sets contract precedence value to 1) 
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9. (Optional) Enable TOS overwriting for the BWM contract. 


>> BWM Contract 1# wtos ena 

(Enables overwriting for contract) 

Set the bandwidth policy for this contract. 


Each bandwidth management contract must be assigned 

a bandwidth policy. 

>> BWM Contract 1# pol 1 

(Assign policy 1 to BWM contract 1) 

Enable the BWM contract. 

» BWM Contract 1# ena 

(Enables this BWM contract) 


12. Classify the frames for this contract and assign the BWM contract to the filter. 

Each BWM contract must be assigned a classification policy. The classification can be based on 
a filter or service(s) on the Virtual server. Filters are used to create classification policies based 
on the IP source address, IP destination address, TCP port number, UDP, and UDP port number. 


>> BWM Contract 1# /cfg/slb/virt 1/cont 1 (Assign contract to virtual server) 

» Virtual Server 1# ,,/filt 1/adv/cont 1 (Assign contract 1 to filter 1) 

In this case, all frames that match filter 1 or virtual server 1 will be assigned contract 1. 

13. On the switch, apply and verify the configuration. 

>> Filter 1 Advanced# apply (Make your changes active) 

» Filter 1 Advanced# /cfg/bwm/cur (View current settings) 

Examine the resulting information. If any settings are incorrect, make any appropriate changes. 

14. On the switch, save your new configuration changes. 

>> Bandwidth Management# save (Savefor restore after reboot) 


15. On the switch, check the BWM information. 


» Bandwidth Management# /info/bwm <contract number>(View BWM information) 
» Bandwidth Management# /stats/bwm <contract number>(View BWM information) 


Check that all BWM contract parameters are set correctly. If necessary, make any appropriate 
configuration changes and then check the information again. 
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Additional Configuration Examples 

Examples are provided for the following: 

■ User/Application Fairness: see next section 

■ Preferential Services: page 363 

■ Security Management: page 371 

User/Application Fairness Example 

Bandwidth Management can be applied to prevent heavy bursters from locking out other users, 
such as in preventing the following: 

■ Customers using broadband access (such as DSL) from blocking dial-up customers 

■ Customers from the same hosting facility locking out each other because of flash crowd 

■ FTP from locking out Telnet 

■ Rate limit particular applications 

In the following example, BWM is configured to prevent broadband customers from affecting 
dial-up customer access. This is accomplished by setting higher bandwidth policy rate limits 
for the port processing broadband traffic. 

1. Select the first bandwidth policy. 

Each policy must have a number from 1 to 64. 

NOTE — Ensure BWM is enabled on the switch (/cfg/bwm/on). 


>> # /cfg/bwm/pol 1 (Select BWM policy 1) 

2. Set the hard, soft, and reserved rate limits for the bandwidth policy, in Mbps. 


>> Policy 

1# 

hard 

5 

(Set “never exceed” rate) 

>> Policy 

1# 

soft 

4 

(Set desired bandwidth rate) 

>> Policy 

1# 

resv 

3 

(Set committed information rate) 


3. On the switch, select a BWM contract and name the contract. 

Each contract must have a unique number from 1 to 256. 


>> Policy 1# /cfg/bwm/cont 1 (Select BWM contract 1) 

» BWM Contract 1# name dial-up (Assign contract name “dial-up”) 
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4. Set the bandwidth policy for this contract. 

Each BWM contract must be assigned a bandwidth policy. 



» BWM Contract 1# pol 1 

( Assign policy 1 to BWM Contract 1) 

5. 

Enable this BWM contract. 



>> BWM Contract 1# ena 

{ Enables this BWM contract) 

6. 

Select the second bandwidth policy. 



» BWM Contract 1# /cfg/bwm/pol 2 

(Select bandwidth policy 2) 

7. 

Set the hard, soft, and reserved rate limits for this policy, in Mbps. 


» Policy 2# hard 30 
» Policy 2# soft 25 
» Policy 2# resv 20 

(Set “never exceed” rate ) 

(Set desired bandwidth rate) 

(Set committed information rate) 

8. 

On the switch, select the second BWM contract and name the contract. 


>> Policy 2# /cfg/bwm/cont 2 

>> BWM Contract 2# name broadband 

(Select BWM contract 2) 

(Assign contract name "broadband” ) 

9. 

Set the bandwidth policy for this contract. 



Each BWM contract must be assigned a bandwidth policy. 


>> BWM Contract 2# pol 2 

(Assign policy 2 to BWM contract 2) 

10. 

Enable this BWM contract. 



» BWM Contract 2# ena 

(Enables this BWM contract) 
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11. Assign the BWM contracts to different switch ports. 

Physical switch ports are used to classify which frames are managed by each contract—that is, 
one BWM contract will be applied to all frames from a specific port. The second contract will 
be applied to all frames from another specified port. 


>> 

>> 

BWM Contract 2# /cfg/port 1/cont 1 
Port 1# ../port 2/cont 2 

(Assign contract 1 to port 1) 

(Assign contract 2 to port 2) 

On the switch, apply and verify the configuration. 

>> 

Port 2# apply 

(Make your changes active) 

>> 

Port 2# /cfg/bwm/cur 

(View current BWM settings) 


Examine the resulting information. If any settings are incorrect, make any appropriate changes. 

13. On the switch, save your new configuration changes. 


>> Bandwidth Management# save 


(Save for restore after reboot) 


14. On the switch, check the BWM information. 


>> Bandwidth Management# /info/bwm <contract number> (View BWM information) 


Check that all BWM contract parameters are set correctly. If necessary, make any appropriate 
configuration changes and then check the information again. 
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Preferential Services Examples 

BWM can be used to provide preferential treatment to certain traffic, based on source IP 
blocks, applications, URL paths, or cookies. You may find it useful to configure higher policy 
rate limits for specific sites, for example, those used for e-commerce. 

Web Site Preference Example 

In the following example, there are two Web sites, “A.com” and “B.com.” BWM is configured 
to give preference to traffic sent to Web site “B.com:” 

1. Configure the switch as you normally would for SLB. Configuration includes the follow¬ 
ing tasks: 

■ Assign an IP address to each of the real servers in the server pool. 

■ Define an IP interface on the switch. 

■ Define each real server. 

■ Define a real server group. 

■ Define a virtual server. 

■ Define the port configuration. 

For more information about SLB configuration, refer to “Server Load Balancing” on page 67. 


NOTE — Ensure BWM is enabled on the switch (/cfg/bwm/on). 

Select the first bandwidth policy. 


Each policy must have a number from 1 to 64. 


>> # /cfg/bwm/pol 1 

(Selec t BWM policy 1) 

Set the hard, soft, and reserved rate limits for the bandwidth policy in Mbps. 

>> Policy 1# hard 10 
» Policy 1# soft 8 
» Policy 1# resv 5 

(Set “never exceed" rate) 

(Set desired bandwidth rate) 

(Set committed information rate) 

On the switch, select a BWM contract and name the contract. 

Each contract must have a unique number from 1 to 256. 


» Policy 1# /cfg/bwm/cont 1 

» BWM Contract 1# name a.com 

(Select BWM Contract 1) 

(Assign contract name “a.com”) 
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5. Set the bandwidth policy for this contract. 

Each BWM contract must be assigned a bandwidth policy. 



>> BWM Contract 1# pol 1 

(Assign policy 1 to BWM contract 1) 

6. 

Enable this BWM contract. 



>> BWM Contract 1# ena 

(Enables this BWM contract) 

7. 

Select the second bandwidth policy. 



>> BWM Contract 1# /cfg/bwm/policy 2 

(Select BWM policy 2) 

8. 

Set the hard, soft, and reserved rate limits for this policy, in Mbps. 


>> Policy 2# hard 18 
>> Policy 2# soft 15 
>> Policy 2# resv 10 

(Set “never exceed” rate) 

(Set desired bandwidth rate) 

(Set committed information rate) 

9. 

On the switch, select the second BWM contract and name the contract. 


>> Policy 2# /cfg/bwm/cont 2 

>> BWM Contract 2# name b.com 

(Select BWM contract 2) 

(Assign contract name “ b.com ”) 

10. 

Set the bandwidth policy for this contract. 



Each BWM contract must be assigned a bandwidth policy. 


>> BWM Contract 2# pol 2 

(Assign policy 2 to BWM contract 2) 

11. 

Enable this BWM contract. 



>> BWM Contract 2# ena 

(Enables this BWM contract) 
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12. Create a virtual server that will be used to classify the frames for contract 1 and assign 
the Virtual server IP address for this server. Then, assign the BWM contract to the vir¬ 
tual server. Repeat this procedure for a second virtual server. 


NOTE — This classification applies to the services within the virtual server and not to the 
virtual server itself. 


The classification policy for these BWM contracts is based on a virtual server. One of the 
BWM contracts will be applied to any frames that are sent to the virtual server associated with 
that contract. 


>> 

BWM Contract 21 

/cfg/slb/virt 1/cont 1 

(Assign contract to virtual server 1) 

>> 

Virtual 

Server 

1# 

vip 100.2.16.2 

(Set virtual server VIP address) 

>> 

Virtual 

Server 

1# 

ena 

(Enable this virtual server) 

>> 

Virtual 

Server 

1# 

/cfg/slb/virt 2/cont 

2 (Assign contract to virtual server) 

>> 

Virtual 

Server 

2# 

vip 100.2.16.3 

(Set virtual server IP address) 

>> 

Virtual 

Server 

2# 

ena 

(Enable this virtual server) 


13. On the switch, apply and verify the configuration. 


» Virtual Server 2# 

apply 

(Make your changes active) 

>> Virtual Server 2# 

/cfg/bwm/cur 

(View current BWM settings) 


Examine the resulting information. If any settings are incorrect, make the appropriate changes. 

14. On the switch, save your new configuration changes. 


» Bandwidth Management# save 


(Save for restore after reboot) 


15. On the switch, check the bandwidth management information. 


>> Bandwidth Management# /info/bwm <contract number>(View BWM information) 


Check that all BWM contract parameters are set correctly. If necessary, make any appropriate 
configuration changes and then check the information again. 
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URL-Based Bandwidth Management Example 

In this example, you will assign bandwidth based on URL paths. For URL-based server load 
balancing, a user has to first define strings to monitor. Each of these strings is attached to real 
servers, and any URL with the string is load balanced across the assigned servers. 


NOTE — The complete procedure to configure URL-based SLB is described in Chapter 7, 
“Content Intelligent Switching” of the Web OS 9.0 Application Guide. 


The best way to achieve URL-based bandwidth management is to assign a contract to each 
defined string. This allocates a percentage of bandwidth to the string or URL containing the 
string. 

To configure the switch for URL-based bandwidth management, perform the following steps: 


NOTE — Refer to the Web OS Command Reference , Chapter 7, for more information on how to 
create a contract. 


1. Define a load-balancing string for URL-based server load balancing. For example, add 
the string “alteon.” 


>> # /cfg/slb/url/lb/add alteon 


To see the URL path ID assigned for the string “alteon,” execute the cur command: 


>> Server Load Balance Resource# cur 
Number of entries: 2 
1: any, cont 1024 
2: alteon, cont 3 


2. Allocate bandwidth for each string. 

To implement this, assign a BWM contract to a defined string. 

>> Server Load Balance Resource# cont <URLpathlD> <BWM Contract number> 
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3. Configure a real server to handle the URL request. 

To add a defined string: 

>> # /cfg/slb/real 2/layer7/addlb <URLpathID> 

where URL path ID is the identification number of the defined string as displayed when you 
enter the cur command. 

Example: /cfg/slb/real 2/layer7/addlb 3 

4. Either enable Direct Access Mode (DAM) on the switch or configure a proxy IP address 
on the client port. 


Note — if vma is enabled and you are using a proxy IP address, you need to configure proxy 
IP addresses on ports 1 through 8. 


To turn on DAM: 


» # /cfg/slb/adv/direct ena 


To turn off DAM and configure a proxy IP address on the client port: 


>> # /cfg/slb/adv/direct dis 
» # ../port 2/pip 12.12.12.12 
>> # proxy ena 


NOTE — By enabling DAM on the switch or, alternatively, disabling DAM and configuring a 
proxy IP address on the client port, port mapping for URL-based server load balancing can be 
performed. 
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5. Turn on URL-based server load balancing on the virtual server. 

Configure everything under the virtual server as in Configuration Example 1. 


>> # /cfg/slb/virt 1/service 80/httpslb enable urlslb 


If the same string is used by more than one service, and you want to allocate a certain percent¬ 
age of bandwidth to this URL string for this service on the virtual server, then define a rule 
using the urlcont command. 


>> # /cfg/slb/virt 1/service 80/urlcont <URLpathID> <BW Contract number> 


This contract is tied to service 1. The urlcont command will overwrite the contract assigned 
to the URL string ID. 

6. Enable Server Load Balancing. 


>> # /cfg/slb/on 


Cookie-Based Bandwidth Management Example 

In this example, you will assign bandwidth based on cookies. First, configure cookie-based 
server load balancing, which is very similar to URL-based load balancing. Any cookie contain¬ 
ing the specified string is redirected to the assigned server. 

Scenario 1: In this scenario, the Web site has a single virtual server IP address and supports 
multiple classes of users. Turn on cookie parsing for the service on the virtual server. 


>> # /cfg/slb/virt 1/service 80 

>> # httpslb enabled cookie sid 1 8 disable 


1. Define one or more load-balancing strings. 


>> # /cfg/slb/url/lb/add <URLpathID> 


Example: 


>> # /cfg/slb/url/lb/add "Business" 
» # add "First" 

» # add "Coach" 
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2. Allocate bandwidth for each string. 

To do this, assign a BWM contract to each defined string. 

>> # /cfg/slb/url/lb/cont <URLpathID> <BWM Contract number> 

3. Configure a real server to handle the cookie. 

To add a defined string: 

>> # /cfg/slb/real 2/layer7/addlb <URLpathID> 

where URL path ID is the identification number of the defined string. 

Example: 

» # /cfg/slb/real 2/layer7/addlb 3 

4. Either enable DAM on the switch or configure a proxy IP address on the client port. 


NOTE — If VMA is enabled, you need to configure a unique proxy IP address for each port 1-8. 


To turn on DAM: 


>> # /cfg/slb/adv/direct ena 


To turn off DAM and configure a Proxy IP address on the client port: 


» # /cfg/slb/adv/direct dis 
» # ../port 2/pip 12.12.12.12 
» # proxy ena 


NOTE — By enabling DAM on the switch or, alternatively, disabling DAM and configuring a 
Proxy IP address on the client port, port mapping for URL-based load balancing can be per¬ 
formed. 


5. Enable SLB. 


>> # /cfg/slb/on 
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Scenario 2: In this scenario, the Web site has multiple virtual server IP addresses, and the 
same user classification or multiple sites use the same string name. In this scenario, there are 
two Virtual IP (VIP) addresses: 172.17.1.1 and 172.17.1.2. Both the virtual servers and sites 
have first class and business class customers, with different bandwidth allocations, as shown in 
Figure 17-7 on page 370. 



First = 3Mbs 
Business = 2Mbs 


Figure 17-7 Cookie-Based Preferential Services 
The configuration to support this scenario is similar to Scenario 1. Note the following: 

1. Configure the string and assign contracts for the strings and services. 

2. If the same string is used by more than one service, and you want to allocate a certain 
percentage of bandwidth to a user class for this service on the virtual server, then define a 
rule using the urlcont command: 


>> # /cfg/slb/virt 1/service 80/urlcont <URLpath ID> <BW Contract number> 


NOTE — When assigning /cfg/slb/virt 1/service 80/urlcont (contract 1) and 
/cfg/slb/url/lb/cont (contract 2) to the same URL, urlcont will override 
contract 2, even if contract 2 has higher precedence. 
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Security Management Example: 

BWM can be used to prevent Denial of Service (DoS) attacks by a flooding of “necessary 
evil” packets and limiting the rate of TCP SYN, ping, other disruptive packets, and alert¬ 
ing/logging the network manager when soft limits are exceeded. 

In the following example, a filter is configured to match ping packets, and BWM is configured 
to prevent DoS attacks by limiting the bandwidth policy rate of those packets: 

1. Configure the switch as usual for SLB (see “Server Load Balancing” on page 67): 

■ Assign an IP address to each of the real servers in the server pool. 

■ Define an IP interface on the switch. 

■ Define each real server. 

■ Define a real server group. 

■ Define a virtual server. 

■ Define the port configuration. 


NOTE — Ensure BWM is enabled on the switch (/ 

cf g/bwm/on). 

Select a bandwidth policy. 


Each policy must have a number from 1 to 64. 


>> # /cfg/bwm/pol 1 

(Select BWM policy 1) 

Set the hard, soft, and reserved rate limits for this policy in Kilobytes. 

» Policy 1# hard 250k 

(Set “never exceed" rate) 

» Policy 1# soft 250k 

(Set desired bandwidth rate) 

» Policy 1# resv 250k 

(Set committed information rate) 


4. Set the buffer limit for the policy. 

Set a parameter between 8192 and 128000 bytes. The buffer depth for a BWM contract should 
be set to a multiple of the packet size. 


>> Policy 1# buffer 8192 

(Set policy buffer limit of 8192 bytes) 

On the switch, select a BWM contract and name the contract. 

Each contract must have a unique number from 1 to 256. 


>> Bandwidth Management# /cfg/bwm/cont 1 
>> BWM Contract 1# name icmp 

(Select BWM contract 1) 

(Select contract name “icmp ”) 
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6. Set the bandwidth policy for the contract. 

Each BWM contract must be assigned a bandwidth policy. 

>> BWM Contract 1# pol 1 (Assign policy 1 to BWM contract 1) 

7. Enable the BWM contract. 


>> BWM Contract 1# ena 


(Enables this BWM contract) 


8. Create a filter that will be used to classify the frames for this contract and assign the 
BWM contract to the filter. 

The classification policy for this BWM contract is based on a filter configured to match ICMP 
traffic. The contract will be applied to any frames that match this filter 


>> BW Contract 1# /cfg/slb/f ilt 1/proto icmp (Define protocol affected by filter) 
» Filter 1# adv/icmp any (Set the ICMP message type) 

» Filter 1 Advanced# cont 1 (Assign BWM contract 1 to this filter) 

» Filter 1 Advanced# /cfg/slb/f ilt 1/ena (Enable this filter) 

» Filter 1# apply (Port and enable filtering) 


On the switch, apply and verify the configuration. 


>> Filter 1 Advanced# apply 

(Make your changes active) 

>> Filter 1 Advanced# /cfg/bwm/cur 

(View current BWM settings) 

Examine the resulting information. If any settings are incorrect, make the appropriate changes. 

On the switch, save your new configuration changes. 

>> Bandwidth Management# save 

(Save for restore after reboot) 


11. On the switch, check the BWM information. 


>> Bandwidth Management# /info/bwm <contract number> (View BWM information) 


Check that all BWM contract parameters are set correctly. If necessary, make any appropriate 
configuration changes and then check the information again. 
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Glossary 


DIP (Destination IP 
Address) 

The destination IP address of a frame. 

Dport (Destination 
Port) 

The destination port (application socket: for example, http-80/https-443/DNS-53) 

NAT (Network 

Address Translation) 

Any time an IP address is changed from one source IP or destination IP address to another 
address, network address translation can be said to have taken place. In general, half NAT 
is when the destination IP or source IP address is changed from one address to another. 

Full NAT is when both addresses are changed from one address to another. No NAT is 
when neither source nor destination IP addresses are translated. Virtual server-based load 
balancing uses half NAT by design, because it translates the destination IP address from 
the Virtual Server IP address, to that of one of the real servers. 

Preemption 

In VRRP, preemption will cause a Virtual Router that has a lower priority to go into 
backup should a peer Virtual Router start advertising with a higher priority. 

Priority 

In VRRP, the value given to a Virtual Router to determine its ranking with its peer(s). Min¬ 
imum value is 1 and maximum value is 254. Default is 100. A higher number will win out 
for master designation. 

Proto (Protocol) 

The protocol of a frame. Can be any value represented by a 8-bit value in the IP header 
adherent to the IP specification (for example, TCP, UDP, OSPF, ICMP, and so on.) 

Real Server Group 

A group of real servers that are associated with a Virtual Server IP address, or a filter. 

Redirection or 
Filter-Based Load 
Balancing 

A type of load balancing that operates differently from virtual server-based load balancing. 
With this type of load balancing, requests are transparently intercepted and “redirected” to 
a server group. “Transparently” means that requests are not specifically destined for a Vir¬ 
tual Server IP address that the switch owns. Instead, a filter is configured in the switch. 

This filter intercepts traffic based on certain IP header criteria and load balances it. 

Filters can be configured to filter on the SIP/Range (via netmask), DIP/Range (via net- 
mask), Protocol, SPort/Range or DPort/Range. The action on a filter can be Allow, Deny, 
Redirect to a Server Group, or NAT (translation of either the source IP or destination IP 
address). In redirection-based load balancing, the destination IP address is not translated to 
that of one of the real servers. Therefore, redirection-based load balancing is designed to 
load balance devices that normally operate transparently in your network—such as a fire¬ 
wall, spam filter, or transparent Web cache. 

RIP (Real Server) 

Real Server IP Address. An IP addresses that the switch load balances to when requests 
are made to a Virtual Server IP address (VIP). 
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SIP (Source IP 
Address) 

The source IP address of a frame. 

SPort (Source Port) 

The source port (application socket: for example, HTTP-80/HTTPS-443/DNS-53). 

Tracking 

In VRRP. a method to increase the priority of a virtual router and thus master designation 
(with preemption enabled). Tracking can be very valuable in an active/active configura¬ 
tion. 

You can track the following: 

■ Vrs: Virtual Routers in Master Mode (increments priority by 2 for each) 

■ Ifs: Active IP interfaces on the Web switch (increments priority by 2 for each) 

■ Ports: Active ports on the same VLAN (increments priority by 2 for each) 

■ 14pts: Active Layer 4 Ports, client or server designation (increments priority by 2 
for each 

■ reals: healthy real servers (increments by 2 for each healthy real server) 

■ hsrp: HSRP announcements heard on a client designated port (increments by 10 
for each) 

VIP (Virtual Server IP 
Address) 

An IP address that the switch owns and uses to load balance particular service requests 
(like HTTP) to other servers. 

VIR (Virtual Interface 
Router) 

A VRRP address that is an IP interface address shared between two or more virtual rout¬ 
ers. 

Virtual Router 

A shared address between two devices utilizing VRRP, as defined in RFC 2338. One vir¬ 
tual router is associated with an IP interface. This is one of the IP interfaces that the switch 
is assigned. All IP interfaces on the Alteon Web switches must be in a VLAN. If there is 
more than one VLAN defined on the Web switch, then the VRRP broadcasts will only be 
sent out on the VLAN of which the associated IP interface is a member. 

Virtual Server Load 
Balancing 

Classic load balancing. Requests destined for a Virtual Server IP address (VIP), which is 
owned by the switch, are load balanced to a real server contained in the group associated 
with the VIP. Network address translation is done back and forth, by the switch, as 
requests come and go. 

Frames come to the switch destined for the VIP. The switch then replaces the VIP and with 
one of the real server IP addresses (RIP’s), updates the relevant checksums, and forwards 
the frame to the server for which it is now destined. This process of replacing the destina¬ 
tion IP (VIP) with one of the real server addresses is called half NAT. If the frames were 
not half NAT’ed to the address of one of the RIPs, a server would receive the frame that 
was destined for it’s MAC address, forcing the packet up to Layer 3. The server would 
then drop the frame, since the packet would have the DIP of the VIP and not that of the 
server (RIP). 

VRID (Virtual Router 
Identifier) 

In VRRP, a value between 1 and 255 that is used by each virtual router to create its MAC 
address and identify its peer for which it is sharing this VRRP address. The VRRP MAC 
address as defined in the RFC is 00-00-5E-00-01-{ VRID}. If you have a VRRP address 
that two switches are sharing, then the VRID number needs to be identical on both 
switches so each virtual router on each switch knows whom to share with. 
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VRRP (Virtual Router 

Redundancy 

Protocol) 


VSR (Virtual Server 
Router) 
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A protocol that acts very similarly to Cisco’s proprietary HSRP address sharing protocol. 
The reason for both of these protocols is so devices have a next hop or default gateway that 
is always available. Two or more devices sharing an IP interface are either advertising or 
listening for advertisements. These advertisements are sent via a broadcast message to an 
address such as 224.0.0.18. 

With VRRP, one switch is considered the master and the other the backup. The master is 
always advertising via the broadcasts. The backup switch is always listening for the broad¬ 
casts. Should the master stop advertising, the backup will take over ownership of the 
VRRP IP and MAC addresses as defined by the specification. The switch announces this 
change in ownership to the devices around it by way of a Gratuitous ARP, and advertise¬ 
ments. If the backup switch didn't do the Gratuitous ARP the Layer 2 devices attached to 
the switch would not know that the MAC address had moved in the network. For a more 
detailed description, refer to RFC 2338. 

A VRRP address that is a shared Virtual Server IP address. VSR is Alteon WebSystems’ 
proprietary extension to the VRRP specification. The switches must be able to share Vir¬ 
tual Server IP addresses, as well as IP interfaces. If they didn’t, the two switches would 
fight for ownership of the Virtual Server IP address, and the ARP tables in the devices 
around them would have two ARP entries with the same IP address but different MAC 
addresses. 
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